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Abstract 

This  technical  report  brings  together  nine  papers  about  various  aspects  of  the  Garnet  project.  It  is  a  sequel 
to  Computer  Science  Technical  Report  CMU-CS-90-154  which  contained  articles  about  Garnet  from 
1989-1990. 
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The  Garnet  User  Interface  Development  Envjronmeni  conuins  a  comprehensive  set  of  tools  that  make 
it  significantly  easier  to  design  and  implement  highly-inieractive,  graphical,  direct  manipulation  user 
interfaces.  The  lower  layers  of  Garnet  provide  an  object-oriented,  constraint-based  graphical  toolkit  that 
allows  properties  of  graphical  objects  to  be  specified  in  a  simple,  declarative  manner  and  then  maintained 
automatically  by  the  system.  The  higher  layers  of  Garnet  include  a  number  of  interactive  tools  that  aUow 
much  of  the  user  iruerface  to  be  created  by  demonstration  without  programming. 

This  technical  report  collects  together  a  number  of  recent  papers  about  Garnet,  some  of  which  have 
been  or  will  be  published  elsewhere.  Also  included  arc  a  collection  of  pictures  of  applications  created 
using  Garnet.  A  previous  technical  report  (CMU-CS-90-154)  contained  the  papers  from  1989  through 
1990,  incluaing  an  introductory  article  describing  all  of  Garnet  which  appeared  in  IEEE  Computer  in 
November,  1990.  If  you  are  not  familiar  with  Garnet,  it  is  best  to  read  that  article  first.  There  is  also  a 
complete  reference  manual  for  Garnet  that  is  revised  about  every  su  months.  The  current  version  of  the 
manual  is  CMU-CS-90-1 17-R3. 

The  first  four  papers  discuss  the  toolkit  level  of  Garnet.  The  underlying  object  system  is  the  topic  of 
the  first  paper,  page  1.  Next,  is  a  paper  describing  the  constraint  system  (page  17).  These  and  other 
features  contribute  to  a  unique  programming  style  in  Garnet,  as  described  on  page  27,  The  next  paper 
summarizes  some  reasons  that  Garnet  is  good  for  creating  interactive  design  lool.s  (page  45).  The  last  five 
articles  discuss  the  higher-level  tools  in  Garnet.  First,  a  chapter  from  an  upcoming  book  summarizes  all 
the  “demonstrational”  aspects  of  Garnet  (page  69).  The  two  papers  on  the  Gill  interface  builder  describe 
its  technique  for  increasing  application  and  user  interface  separation  (page  89)  and  achieving  consistent 
look-and-feel  across  applications  (page  99).  The  C32  spreadsheet  system  (page  107)  helps  implement 
constraints  when  the  simple  icons  in  Lapidary  arc  insufficient.  The  new  Marquise  tool  allows  the  overaU 
behavior  of  the  interface  to  be  defined  (page  115).  Finally,  a  collection  of  pictures  of  systems  created 
using  Garnet  starts  on  page  123. 

As  mentioned  in  the  articles.  Garnet  is  available  for  anonymous  FTP.  To  retrieve  the  system,  ftp  to 
a. gp.es. cmu.edu  (128.2.242.7).  When  asked  to  log  in.  use  anonymous,  and  your  name  as  the 
password.  Then  change  to  the  garnet  directory  (note  the  double  garnet  s)  and  get  the  READ.ME 
explanation  file: 

f"p>  cd  /usr/gdr-e'- 'ad  ."-e'.  • 
ftp>  get  README 

Now,  follow  the  directions  in  the  README  file.  , 
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Abstract 

KR  is  a  portable  object-oriented  system  with  an  integrated  constraint  maintenance  mechanism.  The 
objea  system  implements  the  prototype-instance  model  and  supports  dynamic  redefinition  of  prototvoes. 
Constraints  express  relationships  among  values,  and  are  specified  using  aibiirary  Lisp  expressions.  The 
constraint  system  transparently  keeps  constraints  up  to  date.  For  maximum  performance,  it  is  closely 
integrated  with  the  object  system.  Several  mechanisms,  such  as  constraint  value  caching  and  copy-down 
inheritance,  are  used  to  improve  performance.  The  close  integration  of  object-oriented  programming  with 
flexible  constrain^  maintenance  makes  the  system  wed  suited  for  a  variety  of  application  programs, 
including  highly  interactive  graphical  applications.  KR  is  the  basic  building  block  of  the  Garnet  user 
interface  development  toolkit. 
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1.  Introduction 

KR  [Giusc  90]  is  a  portable  object-oriented  system  with  an  integrated  constraint  maintenance 
mechanism,  written  in  Common  Lisp.  KR  implements  the  prototype-instance  model  [Lieberman  861,  and 
su{qx}rts  completely  dynamic  redefinition  of  prototypes  with  automatic  change  proijagation. 

The  system  beg:an  as  an  attempt  to  implement  the  best  ideas  found  in  frame  systems  without  incurring 
their  typical  peifbraiance  penalty  [Giuse  89].  Constraint  maintenance  was  first  implemented  as  a  separate 
layer  on  top  of  the  existing  language.  After  that  experiment  proved  successful,  we  integrated  constraints 
with  the  b^c  language  to  provide  efficient  performance.  The  three  components  (object  representation, 
object-oriented  programming,  and  constraint  maintenance)  are  now  closely  integrated  and  present  a 
smooth  interface  to  the  application  programmer. 

KR  provides  the  object-oriented  model  and  constraiiu  maintenance  system  for  Garnet  [Myers  90],  a 
a}mpiehensive  user  interface  development  environment  for  X/1 1.  In  addition  to  being  used  to  implement 
Garnet  itself,  KR  is  the  implementation  language  for  all  Garnet  applications.  Such  applications  range 
firran  simulations  of  computer  security  constraints  (Tygar  87]  to  graphical  editors  such  as  Lapidary 
[Myers  89],  to  visual  programming  applications.  Other  applications  include  speech-understanding 
research  at  Carnegie  Mellon  University  [Young  89]  and  an  intelligent  language  tutoring  system  for 
Chinese  [Giuse  88]. 

Performance  has  remained  a  central  goal  throughout  the  evolution  of  the  system.  We  have  striven  to 
achieve  excellent  performance  for  common  operations,  while  supporting  advanced  features  usually 
associated  with  experimental  systems.  KR  does  not  attempt  to  implement  every  possible  operation. 
Objea-oriented  programming,  in  particular,  is  simpler  than  in  CLOS  [DeMichiel  89),  and  is  carefully 
tailored  for  typical  Garnet  applications. 

KR  is  the  only  widely-used  system  that  implements  the  prototype-instance  model  of  inheritance.  This 
model  provides  maximum  flexibility,  because  any  object  can  be  used  as  a  prototype  for  other  objects. 
The  notion  of  class,  in  particular,  is  absent.  For  emphasis,  we  will  use  the  terms  ‘prototype’  and 
‘instance’  in  the  remainder  of  this  paper.  It  should  be  remembered,  however,  that  in  KR  there  is  no 
conceptual  difference  between  those  two  lenns.  The  same  object  can  function  as  both  a  prototype  and  an 
instattee. 

Changes  te  an  object  used  as  a  prototype  are  always  reflected  in  instances,  including  existing  ones. 
Consider,  for  example,  a  prototype  for  rectangles.  The  prototype  typically  supplies  default  values  for 
such  parameters  as  border  thickness  and  filling  color.  Rectangles  created  as  instances  of  the  prototype 
will  then  inherit  those  parameters,  unless  the  programmer  explicitly  overrides  them.  The  prototype- 
instance  model  aUows  the  values  in  the  prototype  to  be  modified  at  any  time.  AH  rectangle  instances  arc 
then  automatically  modified  to  reflect  the  changes.  It  is  even  possible  to  change  dynamically  the 
prototype  used  for  an  instance.  For  example,  an  object  with  a  rectangle  prototype  could  be  modified  to 
become  an  instance  of  a  circle  instead.  All  necessary  changes  happen  automatically. 

The  complete  integration  of  KR  objects  and  constraints  allows  the  application  programmer  to  use 
constraints  for  operations  that  would  typically  be  implemented  as  (combinations  oO  methods  in 
traditional  object-oriented  systems.  This  results  in  a  highly  declarative,  rather  than  procedural, 
programming  style  [Myers  92], 
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KR  integrates  ideas  from  several  areas,  including  object-oriented  systems,  frame  systems,  and 
constraint  systems.  The  resulting  combination  provides  a  unique  mix  of  object-oriented  programming 
and  a  declarative  style  of  programming  with  constraints. 

Historically,  the  first  influence  on  KR  came  from  frame  systems.  Systems  such  as  KL-ONE  [Brachman 
77]  and,  especially.  SRL  [Fox  et  al.  84,  Wright  and  Fox  83]  were  the  primary  influences.  Unlike  those 
systems,  however,  KR  limits  the  number  of  features  in  order  to  achieve  excellent  performance.  The 
system,  in  fact,  began  as  an  attempt  to  implement  the  best  ideas  from  frame  systems  without  incurring  the 
perfoimaiKX  penalty  usually  associated  with  them  [Giuse  89,  Giuse  90].  In  order  to  achieve  good 
performance,  KR  omits  user-controlled  inheritance  paths,  path  grammars,  slot  specifiers,  and  multiple 
contexts.  However,  it  retains  several  of  the  dynamic  features  associated  with  frame  systems,  such  as 
user-defined  inheritance  slots,  multiple  irtheritance,  and  the  ability  to  add  any  slot  to  any  object.  Unlike 
SRL,  KR  allows  the  user  to  set  slots  even  without  a  prior  declaration:  setting  a  slot’s  value  creates  the 
slot,  if  ntme  previously  existed. 

The  nbjea-oriented  component  was  also  partially  influenced  by  SRL.  Like  that  system,  KR  does  not 
distinguish  between  methods  and  ordinary  values:  any  slot  can  contain  a  value  or  a  method.  As  in  SRL 
and  Flavors  [Weinreb  and  Moon  81],  methods  are  invoked  by  sending  a  message.  KR  does  not  support 
generic  functions,  as  found  in  both  C-m-  [Stroustrup  86]  and  CLOS  [Bobrow  et  al.  89],  The  primary 
reason  for  this  choice  is  that  much  of  the  functionality  usually  associated  with  generic  functions  is 
implemented  as  constraints  in  KR. 

The  constraint  maintenance  component  was  initially  modeled  after  Coral  [Sz-ekely  and  Myers  88],  an 
experimental  constraint  system  written  in  CLOS.  Coral,  however,  provided  only  a  small  portion  of  the 
iiKiirea  reference  constraints  functionality  found  in  KR.  Whereas  in  KR  a  constraint  can  reference 
arbitrary  objects  either  directly  or  indirectly  (by  referring  to  slots  that  contain  pointers  to  objects).  Coral 
only  allowed  the  user  to  provide  fixed  lists  of  object  names.  The  KR  approach  is  much  more  flexible, 
because  it  supports  dynamic  redefinition  of  the  path  leading  to  a  desired  value  through  any  number  of 
objects,  and  dynamic  changes  to  objects. 

Because  much  of  what  programmers  do  is  exploratory  programming,  KR  does  not  force  any  compile- 
time  typing,  but  rather  relies  on  Lisp’s  runtime  type  checking.  This  approach  is  similar  to  that  used  in 
other  object-oriented  systems  such  as  Smalltalk-80  (Tesler  81,  Goldberg  and  Robson  83]  and  SELF 
[Ungar  and  Smith  91],  but  unlike  the  C-t-+  compile-time  typing  system. 

Several  object-oriented  systems  advocate  restricting  access  to  object  slots  via  a  method-based  interface. 
This  approach,  already  found  in  Ravors,  is  best  exemplified  by  SELF,  in  which  message  passing  is 
considered  the  fundamental  operation  and  objects  access  state  solely  by  passing  messages.  KR  takes  the 
opposite  approach.  Given  the  combination  of  object-oriented  programming  and  constraint  maintenance, 
most  KR  programs  use  constraints  as  the  primary  abstraction,  and  therefore  access  state  directly  via  slots. 


3.  The  Object  Model 

KR  supports  both  named  and  unnamed  objects.  Objects  in  KR  are  collections  of  attribute/valuc  pairs. 
Each  attribute,  known  as  a  slot,  has  a  name,  which  is  unique  within  an  object.  KR  objects  arc  lypic-aily 
created  using  the  macro  CREATE-INSTANCE.  which  allows  the  u.ser  to  specify  a  prototype  for  the  object  as 
well  as  a  series  of  slots/values  it  is  possible  to  specify  MIL  as  the  prototype,  in  which  case  the  new  object 
does  not  have  any  prototype  (at  least  initially).  The  following  call  creates  a  new  object  named  rect  i 
with  two  slots,  LEFT  and  HEIGHT,  and  no  prototype: 

(create-instance  'RECT-1  nil  (-.Left  20)  (iheight  25)) 
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A  slot  contains  a  single  value,  but  the  value  can  be  of  any  Lisp  type  (such  as  a  list  or  an  array).  Lisp 
functions  can  be  stored  in  ordinary  slots,  and  can  then  be  invoked  as  methods.  The  system  does  not 
require  methods  to  be  defined  or  installed  specially,  although  the  macro  DEFiNE-MFrrHOD  is  provided  for 
convoiience.  A  special  type  of  value,  known  as  a  formula,  is  used  to  implement  constraints,  as  explained 
below.  A  formula  specifics  Iww  to  compute  a  value  based  on  other  values.  When  a  depended  value 
changes,  the  fonnula  is  (logically)  reevaluated. 

Slot  names  in  KR  begin  with  a  colon.  Any  slot  can  be  dynamically  added  to  or  removed  from  an 
object,  whether  cu*  not  the  slot  is  defined  in  any  prototype.  Setting  an  object’s  slot  with  a  value 
automatically  creates  the  slot,  if  needed.  This  m^es  it  extremely  easy  to  associate  any  piece  of 
information  with  any  object,  since  slot  names  do  not  have  to  be  predefined.  For  example,  one  can  set  the 
value  of  slot  :PERIMETER  in  object  RECT-i  by  typing; 

(s-value  RECT-1  :periineter  125.5) 

The  macro  S-ValUE  is  used  to  set  the  value  of  a  slot  of  an  object,  creating  the  slot  if  needed  and  replacing 
any  value  that  was  there  previously.  The  same  function  is  also  used  to  install  a  constraint  on  a  slot. 

Internally,  slots  can  be  of  two  types.  The  first  type,  known  as  a  system-defined  slot,  is  used  for  slots 
that  are  common  to  most  objects.  Examples  include  the  :IS-a  slot,  which  points  to  the  prototype  of  an 
object,  and  the  :LEFT  slot,  which  indicates  the  leftmost  edge  of  a  graphical  object.  System -defined  slots 
provide  highly  optimized  access.  KR  macros  such  as  G-value  (which  retrieves  the  value  of  a  slot)  and 
S-VALUE  expand  into  simple  array  references  for  system-defined  slots.  System-defined  slots  also  use  less 
storage  that  ordinary  slots,  because  their  position  is  known  at  compile  time.  System-defined  slots  are 
hard-wired  into  KR.  and  the  application  programmer  cannot  define  new  ones  at  run  time.  Adding  system- 
defined  slots  at  the  KR  level,  however,  is  extremely  simple  (although  a  recompilation  is  necessary), 
making  it  easy  to  accommodate  the  evolving  needs  of  the  Garnet  system . 

The  second  type  of  slot  are  user-defined  slots.  Any  object  can  have  as  many  user-defined  slots  as 
needed.  Such  slots  are  slightly  less  efficient  than  system-defined  ones,  both  in  terms  of  performance  and 
of  storage.  Note  that  the  distinction  between  system-defined  and  user-defined  slots  is  invisible  to  the 
user.  Note  also  that  there  is  ik>  distinction  in  KR  between  class  variables  and  instance  variables;  KR  slots 
can  be  used  either  way,  and  their  status  can  be  changed  dynamically. 

The  slots  of  an  object  are  stored  in  a  variable-length  array.  In  addition  to  a  value,  each  slot  also 
contains  information  which  is  used  internally  by  KR,  as  shown  in  Figure  1 .  KR  objects  are  represented  as 
Lisp  structures  with  two  structure  slots.  The  first  entry  is  the  name  of  the  object,  or  NIL  for  unnamed 
cbiects.  The  second  entry  contains  the  variable-length  array  of  slot  descriptors. 

Each  system-defined  slot  is  represented  by  three  entries  in  the  array.  User-defined  sloLs  take  four 
entries,  because  the  slot  name  needs  to  be  stored  as  well.  The  first  piece  of  information  in  a  slot  is  the 
slot’s  current  value  (25  in  the  example).  A  special  marker  indicates  slots  that  have  no  value. 

The  second  piece  of  information  associated  with  each  slot  is  a  collection  of  bits,  encoded  as  an  integer, 
which  determine  the  characteristics  of  the  slot.  Currently,  three  bits  are  used.  The  first  bit.  inherited-bit. 
indicates  whether  the  value  in  the  slot  was  inherited  from  a  prototype.  The  second  bit,  is-parent-hit. 
indicates  whether  any  instance  of  the  object  has  inherited  the  value  from  this  slot.  The  third  bit. 
constant-bit,  indicates  whether  the  slot  is  declared  constant  or  was  inferred  constant  (see  below). 

The  third  piece  of  information  in  a  slot  is  the  list  of  formulas  that  depend  on  the  value  in  the  slot.  In 
Figure  1  this  is  shown  as  a  list  of  three  formulas  (unnamed  formulas  are  printed  as  ”F"  followed  by  a 
unique  integer).  This  list  is  used  to  notify  all  formulas  that  are  potentially  affected  whenever  the  value  of 
the  slot  is  modified.  Slots  that  have  only  one  dependent  do  not  .store  a  list,  but  just  the  formula  itself. 


3.1  Inheritance 

Inheritance  in  KR  occurs  through  inheritance  slots,  i.e.,  slots  that  have  been  declared  to  the  system 
using  the  macro  create-RELATION.  The  only  system-defineo  inlKritance  slot  is  :IS-a.  Its  automatically 
maintained  inverse  slot.  ;IS-A-INV,  lists  all  instances  of  an  object,  and  is  used  to  propagate  changes 
automatically.  The  user  may  also  declare  new  inheritance  slots,  with  or  without  inverse  slots.  User- 
defined  inheritance  slots  provide  the  same  inheritance  behavior  as  the  :1S-a  slot. 

Inheritance  slots  (such  as  ;IS-A)  may  contain  one  or  more  values.  Thus,  KR  implements  dynamic 
multiple  inheritance,  both  through  multiple  values  in  the  ;IS-A  slot,  and  through  multiple  inheritance  slots 
in  the  same  object  The  :1S-A  hierarchy  is  searched  first  for  inheritance.  If  no  values  are  inherited  through 
the  :IS-A  hierarchy,  and  other  inheritance  slots  are  present  the  other  slots  are  then  searched  in  turn. 
Multiple  inheritance  is  not  currently  used  in  Garnet,  but  some  non-Gamet  applications  use  it. 

The  following  code  creates  the  two  objects  A  and  B,  and  connects  B  to  A  via  the  .IS-a  slot; 

(create-instance  'A  nil  (:left  10))  ;  create  top  object,  A 

(create-instance  'B  A  (:top  15))  ;  B  :is-a  A 

Printing  objects  A  and  B  shows  the  following: 

{A  :LEFT  -  10 

tIS-A-INV  =»  B }  ;  automatically  created  inverse  slot 

{B  :IS-A  =  A  ;  inheritance  slot 

;TOP  »  15} 

Note  that  slot  IS-a-INV  is  automatically  set  by  the  system.  Because  is  a  is  an  inheritance  slot,  asking 
for  the  value  of  slot  :LEFT  in  B  would  return  the  value  10.  inheriting  it  from  A. 

Access  to  inherited  slots  is  a  potential  performance  bottleneck.  KR  implements  a  careful  tradeoff 
between  access  time  and  storage  requirements.  When  an  instance  is  first  created,  only  slots  that  are 
specifically  defined  by  the  user  are  actually  created  as  local  slots.  In  the  example  above,  slot  left  in 
object  B  is  not  created,  because  it  is  not  mentioned  explicitly.  When  the  value  of  a  slot  is  requested  and  is 
not  present  locally,  the  system  examines  the  inheritance  hierarchy,  looking  for  a  prototype  which  supplies 
a  value  for  the  slot.  If  one  is  found,  the  system  copies  the  value  into  the  instance  and  ail  intervening 
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prototypes  (if  any).  The  is-parent-bit  is  set  in  the  slot  from  which  the  value  is  inherited,  and  in  all  the 
intervening  prototypes. 

When  an  inherited  value  is  copied  down,  it  is  marked  as  inherited  via  the  inherited-bit  of  each  slot  into 
which  it  is  copied.  A  subsequent  request  for  the  slot  will  then  find  the  inherited  value  locally,  and  thus 
will  be  just  as  efficient  as  a  local  slot  access.  Inheritance,  therefore,  uses  a  lazy  copy-down  mechanism, 
since  no  copy  is  made  until  a  value  is  actually  requested.  This  solution  represents  an  effective  tradeoff 
between  storage  (which  is  only  allocated  when  needed)  and  access  time  (which,  except  for  the  very  first 
time,  is  just  as  fast  as  local  access). 

Implementing  inheritance  via  lazy  copying  of  values  horn  prototypes  to  instances  requires  special  care 
wlMi  changes  are  made  to  the  hierarchy,  or  to  one  of  the  prototypes.  In  the  example  above,  changing  slot 
:LEFT  in  object  A  must  also  change  the  copy  of  the  value  in  slot  .-LEFT  of  object  B,  since  the  latter  inherited 
its  value  fimn  a  Similarly,  a  change  in  the  inheritance  hierarchy  (such  as  changing  slot  :1S-a  in  object  B) 
would  also  cause  old  inherited  values  to  become  invalid. 

KR  handles  such  situations  by  recursively  eliminating  from  instances  all  the  values  that  have  been 
inherited  from  their  prototypes.  When  an  inherited  value  is  eliminated  from  an  instance,  it  is  replaced  by 
a  special  no-value  marker  which  can  never  appear  as  a  user-defined  value.  Additionally,  the  inherited-bit 
is  cleared.  The  slot,  then,  looks  exactly  like  a  newly  created  slot  that  has  never  been  accessed.  The 
change  is  recursively  propagated  down  the  hierarchy,  stopping  whenever  an  empty  slot  is  reached,  or 
whenever  a  slot  is  found  for  which  a  local  value  was  defined.  The  advantage  of  this  scheme  is  that  if  the 
slot  in  the  prototype  is  changed  again,  it  is  not  necessary  to  revisit  the  entire  subtree  of  instances. 

It  might  seem  that  during  this  recursive  down-propagation  one  could  simply  set  slots  to  the  new  value 
in  the  prototype,  rather  than  to  the  special  no-value  marker.  However,  this  is  undesirable  for  two  reasons. 
First  of  all,  if  the  new  value  is  a  formula,  a  new  copy  of  the  formula  would  be  required  for  each  slot  which 
had  inherited  the  value,  because  formulas  contain  local  information  for  each  slot.  Second,  this  approach 
would  fail  in  tlM  case  of  multiple  inheritance,  because  some  of  the  instances  might  in  fact  have  inherited 
values  from  a  difierent  prototype.  In  the  presence  of  multiple  inheritance,  the  current  approach  ensures 
that  when  a  value  is  requested  it  will  be  inherited  from  the  correct  prototype. 

An  interesting  case  of  inheritance  is  structural  inheritance,  which  refers  to  composite  objects  (i.e., 
objects  that  contain  other  objects  as  their  components).  When  an  instance  of  a  composite  object  is 
croated,  the  system  arranges  for  the  entire  structure  to  be  copied.  In  addition  to  an  instance  of  the  object, 
instances  of  each  component  are  also  created,  and  the  structural  connections  among  the  various  objects 
are  set  appropriately.  Structural  inhe.itance  is  an  extremely  powerful  abstraction,  because  it  frees  the  user 
from  having  to  know  whether  an  object  being  instanced  is  simple  or  composite.  Even  more  imponantly, 
KR’s  prototype-instance  model  means  that  any  later  change  to  the  original  composite  object  (the 
prototype)  will  be  automatically  reflected  in  its  instances.  It  then  becomes  possible  to  alter  a  prototype 
dynamically  and  have  the  modifications  propagate  immediately  to  any  instance. 


4.  Object-Oriented  Programming 

Object-oriented  programming  in  KR  is  implemented  via  methods.  Methods  are  procedural  attachments 
that  can  be  associ^ed  with  any  object  using  DEnNE-METHOD,  or  simply  by  setting  a  slot  to  a  function 
value  using  S-value.  Internally,  methods  are  stored  in  slots,  just  like  any  other  KR  value;  the  system 
does  not  limit  the  number  or  types  of  methods  that  can  be  defined.  Methods  can  be  created  or  modified 
dynamically,  and  any  object  can  redefine  any  of  its  methods  as  needed.  If  a  locally  redefined  method  is 
eliminated,  the  prototype -defined  method  is  automatically  reu.scd.  This  fully  dynamic  approach  to 
method  handling  is  more  reminiscent  of  full-fledged  frame  systems  such  as  SRL  than  of  traditional 
object-oriented  systems. 
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A  method  in  KR  is  invoked  by  sending  a  message  to  an  object  via  the  macro  kr-SEND.  In  mos'  cases, 
metlrads  are  not  actually  defined  at  the  level  of  an  individual  object,  but  are  inherited  from  its 
prototype(s).  Of  course,  the  nornial  copying  down  mechanism  is  used  for  methods  that  are  inherited  from 
some  prototype.  KR  provides  facilities  to  affect  method  combination,  specifically  a  function  that  allows  a 
method  to  invoke  a  less  specific  method  defined  by  some  prototype  of  the  current  object.  This  part  of  the 
langu:^  is  not  as  complex  as  in  other  Lisp-based  object-oriented  systems  such  as  O-OS,  however, 
because  usually  KR  programs  use  a  declarative  approach  based  on  constraints  [Myers  92’  instead  of 
methods. 

In  addition  to  supplying  default  values,  methods,  and  constraints,  KR  prototypes  are  also  used  to 
control  the  initialization  of  instances.  Immediately  after  an  instance  is  created,  the  system  looks  for  an 
ilNTTlALlZE  method  (which  is  typically  inherited).  If  one  is  defined,  the  system  invokes  it  with  the  new 
instance  as  a  parameter.  This  initialization  mechanism,  akin  to  the  one  provided  by  many  class-based 
objea  systems,  allows  instances  to  be  initialized  using  arbitrarily  complex  user-defined  methods. 

Tire  other  component  of  the  KR  object  model  is  a  demon  mechanism.  It  is  possible  to  associate  with 
each  object  a  demon,  i.e.,  a  procedural  attachment  that  is  invoked  when  certain  slots  in  the  object  are 
modified.  Using  demons,  idl  applications  can  effectively  implement  active  values.  Two  separate 
demons  are  executed  at  different  stages  in  the  value  modification  cycle  (currently.  Garnet  only  uses  the 
first  one).  The  first  demon  is  the  invalidate  demon.  It  is  executed  when  a  slot  is  invalidated,  typically 
because  the  slot  contains  a  formula  which  depends  on  a  value  that  changed.  The  invalidate  demon  is 
executed  with  the  old  value  still  in  the  slot,  allowing  the  demon  to  record  the  old  value,  if  so  desired.  The 
second  demon  is  the  pre-set  demon.  It  is  invoked  immediately  before  the  value  in  a  slot  is  actually  set. 
The  primary  difference  between  the  two  demons  is  the  timing:  the  invalidate  demon  is  called  immediately 
after  a  formula  becomes  invalid,  but  the  pre-set  demon  is  not  called  until  the  value  of  the  formula  is 
demanded.  If  the  value  of  a  formula  is  never  demanded,  the  pre-set  demon  may  never  be  called,  but  the 
invalidate  demon  is  always  called.  Note  that  the  invalidate  demon  is  called  only  when  a  formula  first 
becomes  invalid;  slots  that  contain  already  invalid  formulas  are  not  affected. 

When  a  slot  in  an  object  is  modified,  KR  checks  whether  the  slot  requires  a  demon.  This  is  specified 
by  storing  the  list  of  slot  names  in  the  system-defined  slot  :UPDATE-SL0TS.  In  most  cases,  the  list  of  slot 
names  is  actually  inherited  from  some  prototype.  In  Garnet,  this  list  includes  all  the  slots  that  control  the 
graphical  appearance  of  objects.  If  the  changed  slot  is  in  : update  SLOTS,  KR  looks  for  a  demon  for  the 
object.  If  one  is  found,  it  is  called  with  the  object  and  the  slot  as  parameters. 

Because  demons  arc  application-defined,  they  can  perform  any  desired  action.  In  the  Garnet  graphical 
object  system,  for  example,  the  invalidate  demon  is  used  to  support  the  update  algorithm,  which  ensures 
that  incremental  changes  to  objects  are  reflected  in  the  display.  The  Garnet  demon  records  the  fact  that 
the  object  was  modified  by  adding  it  to  a  list  of  "dirty"  objects.  At  the  next  display  update  cycle,  all  dirty 
objects  are  redisplayed  with  their  new  graphical  features. 

5.  The  Constraint  Model 

A  constraint  allows  the  value  in  a  slot  (the  dependent  value)  to  be  computed  Irom  the  values  in  other 
slots.  In  doing  so,  a  constraint  specifies  that  the  dependent  value  must  be  recomputed  when  any  of  the 
other  values  change.  The  current  version  of  KR  implements  lazy  constraint  evaluation,  which  means  that 
recomputation  does  not  take  place  until  needed,  i.e.,  until  the  dependent  value  is  actually  demanded.  An 
eager-evaluation  version  of  constraint  evaluation  is  currcrfly  under  development. 

Constraints  arc  specified  by  a  special  type  of  object,  called  a  formula,  created  by  the  macro  formula 
(and  its  variant  O-FORMULA,  which  is  used  for  compiled  constraints).  Internally,  formulas  arc  nepre.scnted 
as  Lisp  structures.  To  illustrate  the  representation  of  formulas,  consider  executing  the  following  KR 
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code: 

{create-instance  'CIRCLE-2  nil 
{:left  4) 

{:top  (o-formiila  (>  6  (gv  ;SELF  :ieft))))) 

(g-value  CIRCLE-2  ;top) 

The  call  to  CREaTE-INSTanCE  creates  an  object  named  ciRCLE-2,  sets  its  left  slot  to  4,  and  sets  the 
TOP  slot  to  contain  a  formula  which  adds  6  to  the  contents  of  slot  ;LEFT.  The  call  to  G-value  requests  the 
value  of  slot  TOP,  causing  the  formula  to  be  evaluated,  and  returns  the  value  10.  The  internal  structure  of 
the  fonnula  at  this  point  is  illustrated  in  Figure  2. 


Figure  2:  Internal  structure  of  a  KR  formula. 


Two  structure  slots,  on-schema  and  on-slot,  are  used  to  point  to  the  object  and  slot  on  which  the 
formula  is  installed.  The  structure  slot  named  cached-value  holds  the  formula’s  current  cached  value 
Instead  of  re-evaluating  a  formula  every  time  its  value  is  requested,  KR  caches  the  computed  value  in  this 
structure  slot  A  single  valid  bit  (shown  near  the  bottom  of  the  structure)  indicates  whether  the  cached 
value  is  valid.  If  any  of  the  depended  values  change,  the  bit  is  re.sct,  indicating  that  the  cached  value  ha.s 
become  stale  md  the  formula  will  need  to  be  re-evaluated  when  its  value  is  requested. 

The  is-a  stnicturc  slot  is  used  to  point  to  the  formula’s  parent;  in  our  example,  it  contains  nil  bccau.se 
the  formula  does  not  have  any.  The  following  two  structure  slots  contain  the  executable  code  for  the 
formula,  and  the  original  expression  that  was  used  when  the  formula  wa.s  created.  The  next  structure  slot 
contains  an  integer  which  encodes  the  valid  bit  and  the  .so-caJlcd  cycle  number.  KR  u.sc.s  this  number  tor 
two  separate  purposes.  First,  the  number  is  set  to  0  when  the  formula  is  created,  indicating  that  the 
formula  was  never  evaluated.  Second,  KR  uses  the  number  to  detect  constraint  circularities. 

Constraint  circularities  arise  when  two  formulas  depend  on  each  other’s  value.  To  detect  such  cases,  at 
the  beginning  of  each  evaluation  KR  increments  a  global  number.  Before  each  formula  is  evaluated.  KR 
sets  its  cycle  number  to  the  global  number.  Before  evaluating  each  formula,  however,  the  system  checks 
whether  its  cycle  number  equals  the  global  number.  Normally,  cycle  numbers  should  be  smelly  lower 
than  the  global  number.  If  a  formula  is  found  wtosc  cycle  number  equals  the  global  number,  the  formula 
must  have  already  been  visited  during  the  current  evaluation  cycle,  and  hence  must  be  a  part  of  a 
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constraint  circularity.  KR  then  breaks  the  loop  and  returns  the  current  cached  value  of  the  formula  where 
the  circularity  was  detected.  The  values  of  the  other  formulas  in  the  cycle  are  recomputed  accordingly. 

The  final  structure  slot  in  a  formula  contains  a  list  of  dependencies,  which  is  needed  when  the  formula 
is  destroyed.  This  list  allows  the  system  to  remove  the  formula  from  the  depeiKlents-list  of  all  slots  whose 
values  were  requested  by  the  formula.  Without  this  list,  stale  pointers  would  be  left  around  after  a 
formula  is  destroyed. 

Unlike  most  constraint  systems,  in  which  constraints  can  only  be  specified  using  a  restricted  language 
[Vander  Zanden  89,  Boming  79],  constraints  in  KR  can  be.  arbitrary  Lisp  expressions.  It  is  common  for 
application  programmers  to  define  complex  constraint  expressions  that  use  conditionals,  loops,  local 
variables,  and  the  full  range  of  Lisp  functionality.  The  only  limitation  is  that  constraint  expressions 
should  not  have  side  effects,  because  the  system  does  not  guarantee  the  precise  order  of  evaluation  (or 
re-evaiuation)  of  constraints. 

Constraints  are  closely  integrated  with  the  object  model.  First,  a  constraint  is  placed  on  a  slot  simply 
by  setting  the  value  of  the  slot  to  be  a  formula  object.  From  the  user’s  viewpoint,  this  is  identical  to 
setting  a  slot  with  a  regular  value,  except  that  the  value  is  wrapped  in  a  formula  macro  call.  Second,  a  slot 
that  contaiits  a  corrstraim  is  accessed  exactly  like  any  other  slou  constraint  evaluation  is  transparent. 
Third,  change  propagation  is  also  transparenL  When  a  slot  is  changed  using  s-value,  KR  automatically 
checks  whether  the  slot  was  used  in  computing  the  value  of  any  existing  formula.  Ail  dependent  formulas 
are  then  recursively  invalidated,  and  will  be  recomputed  as  needed.  Several  optimizations  are  used  to 
make  this  process  efficient  If  the  slot  is  set  to  the  same  value  it  had  before,  no  invalidation  needs  to 
happen.  Also,  invalidation  stops  as  soon  as  an  invalid  formula  is  reached,  since  the  algorithm  guarantees 
that  all  fonmulas  that  depend  on  that  formula  will  already  have  been  invalidated.  Note  that  the  entire 
process  is  invisible  to  the  user  all  the  user  does  is  to  set  a  value  in  a  slot. 

The  advantages  of  allowing  arbitrary  Lisp  expressions  in  constraints  are  clear.  Progiammers  can 
express  very  complicated  behavior  through  constraints,  c.g.,  determine  the  exact  layout  of  composite 
objects  such  as  trees  or  variously-aligned  lists  of  similar  objects.  Such  complex  constraints  are  typically 
supplied  by  system  implementors  and  inherited  by  all  user-defined  gadgets.  For  example,  the  Garnet 
system  provides  composite  lists  of  gadgets  that  are  fonnatted  using  constraints.  User-defined  gadgets, 
such  as  menus,  that  use  these  lists  automatically  inherit  the  system-defined  constraints. 

Conventional  constraint  systems  typically  need  to  parse  constraint  expressions  and  determine  what 
values  are  being  referenced.  The  fact  that  KR  supports  arbitrary  Lisp  expressions  in  constraints,  however, 
makes  it  impossible  to  precompute  the  list  of  all  depended  values.  A  constraint,  for  example,  may  invoke 
user-defined  functions,  which  might  contain  references  to  arbitrary  values.  KR  .solves  this  problem  by 
arranging  for  dependencies  to  be  computed  dynamically,  as  the  constraint  expression  is  being  evaluated. 
This  is  done  via  the  macro  GV,  Like  G-value,  this  macro  retrieves  the  value  from  a  slot.  In  addition, 
however,  GV  also  records  the  dependency,  if  needed.  Consider  the  following  formula  expression,  which 
computes  the  right  edge  of  an  object  by  adding  the  object’s  width  to  the  left  edge  of  object  rect  3: 

(+  (gv  RECT-3  ;left)  (gv  :SELF  ;width)) 

When  this  expression  is  evaluated,  the  first  GV  adds  the  current  formula  to  the  list  of  dependents  of  slot 
;LEFT  in  object  RECTO  (the  list  of  dependents  is  one  of  the  three  component-s  of  a  slot,  as  5;hown  in  Figure 
1).  The  second  :GV  adds  the  formula  to  the  list  of  dependents  of  slot  ;VVIDTH  in  the  current  object.  Once 
these  dependencies  are  set  up.  KR  will  invalidate  the  formula  whenever  one  of  the  depended  values  is 
modified. 

As  shown  in  the  example,  :SELF  can  be  used  instead  of  an  object  name  to  indicate  the  object  on  which 
the  formula  is  installed.  In  addition,  GV  allows  more  than  one  slot  name  to  be  specified.  For  example,  the 
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following  formula  expression  can  be  used  to  fetch  the  value  of  slot  :LEFT  from  the  object  contained  in  slot 
;PARENT  of  the  current  object;  <gv  :SELF  ;  parent  :left). 

In  this  case,  GV  is  used  to  specify  a  path.  Slot  :Parent  is  accessed  to  yield  an  object.  The  resulting 
objea  is  accessed  and  the  value  of  its  ;LEFT  slot  is  returned.  Because  (gv  ;  self)  is  such  a  common 
idiom,  KR  provides  the  equivalent  macro  GVL.  The  expression  above  could  have  been  written  as  (gvi 
: parent  :left). 

An  advantage  of  computing  dependencies  dyrtamically  is  that  fewer  dependencies  may  be  set  up. 
bn^ine  an  expression  that  contains  a  conditional.  As  long  as  only  one  branch  of  the  conditional  is  taken, 
there  is  no  need  to  establish  dependencies  to  values  that  might  be  needed  in  the  other  branch.  This 
prevents  unnecessary  wortc,  since  a  change  to  one  of  those  values  could  not  affect  the  final  value  anyway. 
Eliminating  the  need  to  parse  constraint  expressions,  therefore,  results  in  greater  flexibility. 

An  important  distinguishing  feature  of  KR  constraints  is  that  they  allow  fully  indirect 
references  [Vander  Zanden  91].  Most  existing  constraint  systems,  by  comparison,  only  allow  hard-wired 
object  references  [Vander  Zanden  89,  Myers  88].  In  KR,  constraints  may  refer  to  slots  of  other  objects 
indirectly.  A  typical  example  of  an  indirect  reference  is  shown  in  Figure  3. 


{dependents;  F183) 

:left  Formula  F183;  (/  (gv  :S6LF  :attached-to  ;left>  2) 

Figure  3;  An  inherited  constraint  which  uses  indirect  rclcrcnccs. 


The  formula  in  slot  :LEFT  of  object  RECT-I2,  FI83,  was  inherited  from  prototype  OBJ-3.  Slot  LEFT  in 
object  RECT-12  is  computed  by  referring  to  slot  :LEFT  in  object  CIRCLE  i.  The  current  value  is  15, 
obtained  by  dividing  30  (the  value  in  CIRCLE- 1)  by  2,  as  specified  in  the  formula.  The  name  of  that  object 
is  stored  in  slot  :ATTached-TO.  Note  that  the  constraint  expression  of  the  formula  refers  to  the  target 
object  only  indirectly,  using  the  contents  of  slot  attached-TO  in  the  current  object  (i.e.,  self).  The 
constraint  is  effectively  parameterized.  Changing  the  value  of  slot  :atTached-TO  in  object  RECT-12  will 
automatically  cause  the  value  of  slot  zLEFT  to  be  recomputed.  The  primary  advantage  of  indirect 
references  is  that  they  allow  generic  formulas  to  be  defined  by  an  object’s  prototype.  Generic  formulas 
can  be  used  verbatim  in  the  instances,  because  they  use  relative  paths  without  hard-wired  object  names. 

Indirect  references  in  KR  constraints  are  possible  because  the  system  records  the  dependency  of  such 
constraints  on  all  the  intervening  links  of  the  chain  of  references.  In  Figure  3.  for  example,  both  the 
:ATTACHED-TO  slot  and  object  circle-i’s  ;LEFT  slot  list  formula  FI 83  as  their  dependent.  If  slot 
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lATTACHED-TO  is  set  to  a  different  value,  say  object  NEW-OBJ,  formula  F183  is  invalidated.  When  the 
value  of  objea  RECT-12’s  iLEFT  slot  is  requested,  the  formula  will  recompute  a  new  value  using  the  left 
slot  of  object  NEW-OBJ. 

It  is  clear  from  the  previous  discussion  that  constraints  interact  with  other  parts  of  KR.  A  first 
interaction  is  between  constraints  and  values,  because  slots  can  contain  either  oixiinary  Lisp  values  or 
fbnnulas.  This  potential  proUem  is  avoided  by  letting  all  slot-accessing  macros,  such  as  G- value  and 
GV,  work  on  either  type  of  slot.  If  a  slot  contains  an  ordinary  Lisp  value,  the  macros  simply  reoim  the 
value.  If  a  slot  contains  a  formula,  the  macros  evaluate  the  formula  first  (if  its  cached  value  is  not  valid) 
and  then  return  the  value.  Tlus  operation  may  actually  trigger  a  complex  chain  of  nested  evaluations, 
because  the  formula  may  depend  on  other  formulas  that  also  need  to  be  re-evaluated.  Ail  of  this, 
however,  happens  transparently. 

A  second  iiueiaction  is  between  constraints  and  inheritance.  Because  inherited  values  are  actually 
copied  from  the  prototype  into  the  instance,  a  change  to  a  prototype  may  modify  the  (inherited)  value  in 
an  instance.  Consider,  for  example,  the  case  where  object  B  (an  instance  of  object  a)  inherits  the  value  of 
its  ;LEFT  slot  from  A.  as  shown  in  Figure  4. 


.  left  31 
(is-inherited) 
(dependents:  F17) 


I _ Q _ i 

:top  Formula  F17:  (gv  0  :left) 


Figure  4:  Modifying  a  slot  in  prototype  A  causes  formula  FI 7  to  be  invalidated. 


Slot  :TOP  of  object  C  is  constrained  to  have  the  same  value  as  object  B’s  :LEFT  slot.  Now,  imagine  that 
slot  -.LEFT  in  object  a  is  changed.  The  value  in  slot  LEFT  of  instance  B  was  inherited,  and  therefore  it 
changes  (more  precisely,  its  value  is  removed  and  replaced  by  a  non-value,  as  explained  in  section  3.1). 
Consequently,  fonnuia  F17  in  slot  :TOP  of  object  C  must  be  invalidated,  since  the  value  on  which  it 
depends  has  changed. 

To  address  this  problem,  the  inheritance  mechanism  described  earlier  is  modified  as  follows.  When  a 
slot  is  changed,  KR  checks  whether  its  previous  value  had  been  inherited  by  some  other  object;  this 
infotmation  is  contained  in  the  is-parent-bit  of  the  slot.  If  so,  the  instances  of  the  object  arc  recursively 
visited.  If  any  instance  had  inherited  the  value,  the  inhented  value  is  removed  from  the  slot.  If,  in 
addition,  some  fonnuia  depends  on  the  instance’s  slot  (as  described  by  the  slot’s  list  of  dependenus).  the 
formula  (and  the  formula’s  own  dependents)  are  recursively  invalidated.  This  process  involves  two 
distinct  graphs;  the  inheritance  hierarchy,  through  which  values  may  have  been  inherited  from  prototypes 
into  instances,  and  the  constraint  graph,  which  determines  how  values  depend  on  other  values. 
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6.  Special  Efficiency  Features 

KR  improves  the  efficiency  of  the  constraint  system  by  caching  computed  values  in  formulas.  After  a 
formula  is  evaluated,  its  value  is  cached  locally  and  can  then  be  used  over  and  over  until  the  fonnula  is 
invalidated.  Access  to  a  cached  value  in  a  formula  is  only  slightly  slower  than  access  to  a  locally  defined, 
regular  value. 

Another  feature  that  is  essential  for  performance  is  that  user-specified  constraints  are  compiled  when 
the  file  diey  are  in  is  a^mpiled.  This  is  possible  because  the  O-FORMULA  macro  expands  into  a  lambda 
form  containing  the  formula  exptessioa  The  resulting  code  is  extremely  efficient  and  takes  advantage  of 
all  the  built-in  optimizations.  Inside  compiled  constraints,  for  example,  slot  accessor  macros  are 
expanded  into  array  references. 

KR  contains  several  user-controlled  features  that  make  it  easier  to  generate  very  efficient  applications. 
First,  much  of  the  error-checking  code  in  the  system  is  cotKlitionally  compiled.  Once  an  application 
program  has  been  thoroughly  tested,  the  user  can  simply  run  the  system  with  the  "no-debug "  version  of 
KR,  which  eliminates  most  error  checks.  A  second  mechanism  allows  the  application  programmer  to 
sp^fy  that  certain  paths  in  indirect  reference  constraints  are  immutable.  For  well-debugged  object 
hierarchies,  this  declaration  allows  constraint  re-evaluation  to  become  considerably  faster  by  avoiding 
unnecessary  path  traversals.  It  also  saves  storage  by  preventing  unnecessary  dependencies  from  being 
created.  A  third  mechanism,  which  is  nearing  completion,  allows  the  programmer  to  declare  that  certain 
slots  in  an  object  arc  "constant”,  i.e.,  their  value  will  never  change  after  the  object  is  created.  This 
information  is  stored  in  a  slot's  constant-bit.  Formulas  that  only  depend  on  constant  slots  can  then  be 
eliminated  automatically,  further  improving  efficiency  and  storage  requirements. 

7.  Conclusions 

The  current  implementation  of  KR  is  the  result  of  our  collective  experience  in  using  the  system  over  the 
past  several  years.  Whenever  a  choice  existed,  we  have  opted  for  solutions  that  could  be  implemented 
efficiently  without  making  the  programming  interface  unnecessarily  complex. 

KR  is  a  very  flexible  object  system.  It  supports  multiple  inheritance  on  both  system-defined  and 
user-defined  inheritance  slots,  automatically  maintained  inverse  slots,  and  the  prototype-instance  model 
of  inheritance.  Prototypes  may  be  modified  dynamically,  and  the  results  arc  immediately  propagated  to 
instaiKes.  Any  object  may  be  used  as  a  prototype;  no  compile-time  declarations  arc  necessary.  Slots  may 
be  added  and  removed  from  objects  at  will.  It  is  also  possible  to  change  the  prototype  of  any  instance 
from  one  object  to  another,  causing  all  values  that  were  inherited  from  the  old  prototype  to  change 
appropriately. 

KR  also  provides  a  very  flexible  constraint  system.  New  constraints  may  be  created  dynamically,  and 
may  be  installed  on  any  slot.  Constraints  can  be  specified  as  arbitrarily  complex  Lisp  expressions. 
Moreover,  constraints  can  use  indirect  references,  which  offer  maximum  flexibility  by  allowing  values  to 
be  obtained  from  different  objects  at  runtime.  Constraints  and  inheritance  interact  properly,  and  changes 
in  the  inheritance  hierarchy  arc  propagated  through  the  constraint  hierarchy  as  well. 

KR  demonstrates  that  object-oriented  programming  and  constraint  maintenance  can  be  effectively 
integrated.  This  combination  results  in  great  flexibility  and  a  unique  programming  style  in  which  much 
of  the  functionality  usually  associated  with  method  invocation  is  performed  by  constraints.  The  system  is 
the  only  widely  used  object-oriented  system  in  which  the  prototype-instance  model  i.s  combined  with 
copy-down  multiple  inheritance.  We  are  currently  experimenting  with  extensions  that  will  further 
improve  performance,  such  as  user-specified  declarations  of  constant  slots  and  eager  constraint 
evaluation. 
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Abstract 

Grat^iical  tools  are  increasingly  using  coostrainu  to  specify 
the  graphical  layout  and  behavior  of  many  parts  of  an  ap¬ 
plication.  However,  cooveotional  constraints  directly  en¬ 
code  the  objects  they  lefetence.  and  thus  cannot  provide 
soppoR  for  the  dynamic  ttmtime  creatioo  and  mantpulatioa 
of  applicatioe  ot^ects.  This  paper  discusses  an  extension  to 
current  eonttraint  models  that  allows  consnaints  to  in¬ 
directly  lefetenoe  objects  through  polnier  variables. 
Pointer  variables  pemiit  programmers  to  oeaie  the  con¬ 
straint  equivdeot  of  procedures  in  traditional  programming 
languages.  Thit  promdural  abstraction  allows  constraints 
to  model  a  wide  array  of  dynamic  ^iplicaiioo  behavior, 
shnpiilks  the  implementation  of  structured  object  and 
demoasttatiooal  systems,  and  improves  the  storage  and  ef¬ 
ficiency  of  highly  inteiactive,  gtaphical  applications.  It 
also  pRxnores  a  simpler,  mote  effective  style  of  program¬ 
ming  than  cooventioaal  caostnints.  Constraints  that  use 
pointer  variables  ate  powerful  enough  to  allow  a  com- 
piebensive  user  interface  tooUut  to  be  built  for  ibe  first  ttme 
•X  top  of  a  constraint  system. 

Kaywonte:  Constraints,  development  tooh.  incremental  al¬ 
gorithms 

1 1ntroduction 

User  interface  toolkits,  particularly  graphical  layout  tools, 
are  increasingly  adopting  the  constraint  model  of  computa- 
tioa  The  constrainl  model  uses  equatixs  to  denote 
relationships  between  two  or  more  objects.  For  example,  a 
designer  might  write  the  following  equation  to  position  a 
circle  10  pixels  to  the  right  of  a  rectangle: 

l«tt  •  ay-raet.rl^ht  ♦  10 
PvwtVMion  to  copy  without  fM  all  or  port  of  thi«  matohal  it 
grantmf  previdod  that  tha  eepiat  ara  not  mada  or  diathbutad  for 
diraet  eotmioreiaf  odvantaga,  tha  ACM  copyright  notica  and  tha 
Pda  of  tha  puMieation  arid  itt  data  appaar.  and  notica  it  givan 
that  copying  it  hy  parmittion  of  tha  Attoeiaoon  for  Computing 
Moehinary.  To  copy  otharwita,  or  to  rapubliah,  raquirtt  a  faa 
and/or  apacifie  parmtston. 
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The  advantage  of  the  constraint  model  is  that  changed  dau 
is  automatically  propagated  to  the  appropriate  places  and 
fclationsbips  are  automatically  maintained.  Thus,  if  a  user 
drags  the  rectangle  around  the  screen,  a  cotutniot  solver 
continuously  resatisfies  the  above  equatix.  causing  the 
dre’n  to  follow  the  rectangle  around  the  display. 

Havmg  a  constnint  solver  automatically  maintain  a  set  of 
lelatioaships  is  obviously  advantagexs,  since  it  saves  the 
programmer  from  having  to  manually  write  code  to  ac¬ 
complish  the  same  task.  However,  cxveatiXal  constrainu 
directly  encode  the  objects  they  leferenx.  For  example, 
■y -rpet  is  hardcoded  into  the  above  constrainl.  Thus  they 
cannot  support  the  dynamic  luntime  creatix  of  objects, 
smee  the  coustiaints  u  the  newly  created  objects  will  refer¬ 
ence  the  wrxg  objects.  These  constraints  also  canxt 
model  any  appiixiix  behavior  which  involves  objects  that 
continuxsly  change  their  relatsoosbips  to  other  Xjecu. 
For  example,  a  feedback  object  must  highlight  any  item  in 
a  menu,  an  arrow  might  point  at  different  boxes  in  a  boxes- 
and-arrows  editor,  and  a  truck  switches  streets  as  it 
uvigates  tfanugb  a  city. 

These  shortcomings  can  be  remedied  by  adding  pointer 
variables  to  exstraints  that  allow  objects  to  indirectly  ref¬ 
erence  otbCT  objects  (these  exstraints  are  called  irudrea 
reference  constrainu).  For  example,  the  above  xostraim 
could  be  irwriitro  as‘: 

l»ft  •  lalf .ob)-ov«r. right  ♦  10 

obj-ovar  •  my -net 

where  seif  refers  to  the  object  extaining  the  variable 
left,  in  this  case,  the  circle.  By  changing  the  value  of  the 
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vaiubie  obj  -ov«r,  tbe  circle  can  be  positioaed  to  ttie  right 
of  any  obje^  With  this  extension,  constnints  can  support 
the  luminc  oeaiioo  of  objects  and  express  the  dyrumic 
behaviors  that  occur  inside  an  appiicahon  window,  as  well 
as  the  static  layout  leiatioosfaips  that  occur  around  the  ap- 
plicatkn  window. 

Pointer  variables  allow  the  progranmer  to  deOne  the  con* 
strahu  equivalent  of  procedures  in  traditional  ptogtauniing 
languages.  Gener^izing  direct  references  into  indirect 
references  is  akin  to  defining  the  patametcrs  of  a  proce¬ 
dure.  The  advantages  of  procedural  abstraction  are  well 
known,  but  the  imitonentatioa  of  pncedural  abstraction  in 
constraint  systems  is  still  quite  novel.  Constraint 
procedural  atairactioos  greatly  sinqtlify  the  implementation 
of  many  interface  features  and  enable  the  implementation 
of  new  ones  that  would  have  been  unwi^y  vnthout 
procedural  abstractioa: 

•  Feedback,  in  which  objects,  such  as  check¬ 
marks  or  inverted  lectaogles,  may  appear  with 
any  item  in  a  set  of  objects; 

•  Prototype-Instance  models,  in  which  instances 
of  coostraints  must  be  inherited  from 
prototypes  and  references  must  be  adjusted  so 
that  they  point  to  the  instance  nther  than  the 
prototype; 

•  Programming  by  example,  in  wtich  con¬ 
straints  that  are  demonstrated  for  example  ob¬ 
jects  must  be  convened  to  general  constraints 
that  woris  with  any  object; 

•  Abstraa  specificatiao  of  layouts,  in  which 
genetic  objects  ate  laid  out  using  constraints, 
and  the  spedlic  widgets  are  filled  in  later, 
based  on  such  parameters  as  the  availabilty  of 
screen  space; 

•  Simulatirais,  in  which  objects  are  freqtxntly 
constrained  to  new  and  diffeient  objects,  for 
exanq)le  objects  moving  between  the 
machine.s  on  a  factory  floor. 

Over  the  last  couple  years,  we  have  gained  considerable 
experience  using  indirect  reference  coustraints  in  the  Gar¬ 
net  project  [11],  We  have  found  that  they  are  crucial  for 
intplementing  the  inqd<»<  of  applicaiioa  windows,  which  is 
the  hardest  and  most  time-coDsuming  portion  of  an  ioter- 
thoe  to  construct  In  Garnet  constraints  consist  of  arbitrary 
pieces  of  Lisp  code  and  consequently,  they  are  used  to 
specify  more  than  just  gr^ttaical  layouts.  For  example,  they 
are  used  to  ccnununicaie  information  between  multiple 
threads  of  a  dialog,  to  compute  the  attribute  values  of  ob¬ 
jects,  and  to  monitor  the  states  of  various  objects.  The 
procedural  abstraction  provided  by  indirect  reference  con- 
stramts  is  so  powerful  that  Garnet  implements  its  toolkit  on 
top  of  the  constraint!  [11].  No  other  constraint-based 
toolkit  does  this. 


lodiiect  reference  constraints  also  provide  an  entirely  new 
style  of  programming  that  seems  much  simpler  and  more 
effective  than  conventional  consaainis.  It  will  become  ap¬ 
parent  bow  indirect  reference  constraints  lead  to  far  simpler 
implementations  as  tins  paper  describes  many  of  the  impor¬ 
tant  q^lications  of  indirea  reference  constraints.  This 
paper  will  also  discuss  bow  indirect  reference  constraints 
can  enhance  the  perfonnance  of  an  application  while 
decreasing  its  storage  demands.  Finally,  various  im¬ 
plementation  strategies  for  indirect  reference  constraints 
will  be  discussed. 

2  Rniatwi  Work 

While  pointer  variables  are  commonly  incorporated  in  pro¬ 
gramming  languages,  tbey  have  only  recently  been  incor¬ 
porated  in  their  fell  generality  in  coostraint  systems.  A 
restricted  version  of  indirect  reference  constrainu  fust  ap¬ 
peared  in  Coral  [17],  Coral  permitted  a  designer  to  provi^ 
a  list  of  objects  that  a  constraint  could  reference.  For  ex¬ 
ample,  a  designer  could  provide  a  list  of  menu  items  and  a 
fr^hack  objea  would  be  able  to  appear  over  any  of  them. 
However,  Coral  did  not  allow  constraints  to  reference  ar¬ 
bitrary  objects  through  variables,  and  thus  did  not  provide 
the  frill  generality  of  indirect  reference  constraints. 

Tbinglab  [2]  also  provides  a  limited  form  of  indirect  refer¬ 
ence  constraints.  Designers  can  coostrua  paiboames  that 
allow  a  coostraint  to  traverse  a  stiuchue  bieraichy  to  find 
an  object  If  one  of  the  components  in  the  scucnire  hierar¬ 
chy  changes,  the  new  object  will  be  automatically 
referenced  by  the  constraint  However,  aibitiaiy  references 
to  objects  through  pointer  variables  are  not  supported.  Fsn- 
guiix»  rn  supports  a  model  of  indirect  reference  constraints 
that  is  similar  to  the  one  described  in  this  paper  but  it  uses  a 
different  constraint  solving  algorithm.  Many  otber  $y$- 
tenas,  such  as  Grow  [1],  Apogee  (S],  Peridot  [9]  and  CON- 
SntAlNT  [19],  allow  constraints  to  directly  reference  ob¬ 
jects  but  do  not  allow  indirect  refeieoces. 

Kaleidoscope  supports  a  different  type  of 
abstraction— constraint  abstraction  rather  than  procedural 
abstraction — in  which  procedures  consist  of  a  set  of 
parameterized  coostraint  statements  and  produce  as  output 
a  set  of  constraints  instantiated  with  the  parameten  passed 
to  the  procedure  [31. 

Fually.  a  number  of  researchers  have  developed  models 
that  allow  constraints  to  have  variables,  but  not  pointer 
variables  [16. 15,  8. 14],  For  example,  a  programmer  could 
write  a  constraint  such  as  fee<iback.position  » 
iumLposiuon  +  offset,  initially  assign  the  value  of  10  to 
offset,  and  later  assign  the  value  of  20  to  offset. 
However,  a  programmer  could  not  write  a  coostraint  of  the 
form  feetOwk-position  *  self. oPj-over. position  +  offset, 
where  obj-over  is  a  pointer  variable  that  points  to  an 
arbitrary  object 
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3  Applications  of  Indirect  Reference  Constraints 

Indirect  reference  coosaaints  can  be  used  to  implement 
many  pans  of  an  applicaiioa  iltai  are  difficult  or  infeasible 
to  is^tlement  wiib  direct  reference  constraints.  These  in¬ 
clude  feedback,  copying  and  instancing  of  composite  ob¬ 
jects  witb  constraims  in  them,  programming  by  txamplt, 
^straa  specification  of  layouts,  and  sinuilatioos. 

XI  Feedback 

Most  direct  manipalatioo  interfaces  provide  feedback  to  tbe 
user  while  performing  an  operaboa  For  example,  a  rec¬ 
tangle  may  bigblight  the  item  Uiat  the  nser  is  ennedtiy 
pointing  at  in  a  menu  (Figure  l.a).  While  it  is  generally 
impractical  to  handle  feedback  objects  using  direct  refer¬ 
ence  constraints,  they  are  easily  handled  using  indirect  ref¬ 
erence  constraints.  For  exanple,  tbe  feedback  objea  in 
Figure  la  must  be  able  to  highlight  any  of  tbe  menu  items, 
but  a  direct  reference  constraint  will  only  allow  it  to  tugb- 
lighi  <»e  of  these  items.  In  contrast  indirect  reference 
constraints  aUow  tbe  feedback  objea  to  reference  any  of 
these  menu  items  through  a  variable,  such  as  obj-ov«r. 
This  technique  works  equally  well  for  feedback  objects  that 
highlight  a  fixed  set  of  objects,  such  as  tbe  objects  in  a 
menu,  or  a  dynamic  set  of  objects,  such  as  the  objects  in  a 
drawing  window  (Figures  l.a  and  l.b). 
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(a)  (b) 

Fignre  1. 

The  rectangular  feedback  object  in  the  menu  and  the 
selection  handles  in  the  drawing  editor  use  constnints 
to  center  themselves  over  the  selected  items  and  to 
change  their  dimensions  to  the  dimensions  of  the 
selected  item.  By  indirectly  accessing  a  selected  item 
through  the  variable  obj  -over,  the  feedback  objects 
are  able  to  appear  both  over  any  item  in  a  static  set  of 
objects,  such  as  the  menu  items  (a),  or  any  item  in  a 
dynamic  set  of  objecu,  such  as  the  objects  in  the  draw¬ 
ing  editor  (b). 


3.2  Strueturad  Objects 

Pointer  vaiizbles  simplify  tire  integration  of  constraints  into 
a  stractuied  objea  system.  A  structured  object  consists  of 
several  parts,  such  as  the  labeled  box  in  Figure  2.  which 
consists  of  a  rectangle  and  a  piece  of  text  Typically  these 
parts  are  mutually  ctmstrained.  Fa  example,  the  label  is 
centered  inside  tbe  box  and  the  size  of  the  box  depends  on 
the  size  of  tbe  label. 


305 


(a) 


Fignre  2. 

Structured  objects,  such  u  this  labeled  box  (a),  are  built 
up  from  ocher  objects,  sucb  ss  this  rectangle  and  number 
(b).  Each  object  maintains  pointers  to  its  parent  and  its 
children,  so  that  constraints  can  indirectly  reference  one 
another  through  pointers.  This  facilitates  the  copying 
and  instancing  of  objects,  since  the  object  system 
simply  sets  the  pointers  in  the  new  objects,  and  the 
constraints  automatically  leference  the  appropriate  ob¬ 
jects  (c). 


Interactive  applications  need  to  make  cqjies  a  instances  of 
these  objects  at  runtime  (e.g.,  creating  new  (Ejects  in  a 
drawing  program,  creating  new  circuit  elements  in  a  circuit 
simulation  program).  These  operations  can  be  easily  im¬ 
plemented  using  indirea  reference  constraints,  but  are  quite 
difficult  to  implement  in  regular  constraint  systems. 

In  an  indirect  reference  coosnaint  system,  each  object 
maintains  a  pointer  to  its  parent,  and  a  set  of  pointen  to  its 
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cMIdren  (Figure  2.b).  Cwstraiats  refereocc  objects  by  fol- 
towiug  the  appropriate  pointers.  For  example,  if  tbe  label’s 
parent  pointer  is  contained  in  the  vaiiable  parent  and  tbe 
labeled  box  keq»  pointeis  to  its  children  in  tbe  vaiiables 
labeo.  and  box,  then  the  label  can  be  centered  inside  tbe 
box  using  die  foUowing  coostnitUs: 

emcex-x  •  self  .parent,  box.  center-v 

eanter*r  •  aalf. parent. box. eeacer*y 

To  aeate  an  instance  of  an  object,  the  Object  system  creates 
instances  of  each  of  the  object’s  components  and  sets  the 
pointer  variables  (Rgure  Ic).  Tbe  object  system  also 
creases  instances  of  each  of  the  constraints  in  the 
prototype’s  components  and  stores  them  in  the  appropnaie 
places  in  the  new  instance’s  components.  No  changes  are 
needed  to  tbe  constraint  expression.  The  constrainu  in  tbe 
newly  created  objects  will  antomaticaUy  reference  the  ap¬ 
propriate  objects  since  they  will  follow  the  pointeis  in  the 
instance  objects  latber  than  in  tbe  prototype  objects.  For 
example,  tbe  consoaint  that  compotes  the  value  for 
c«nt«r-x  in  the  label  instance  will  follow  tbe  parent  and 
box  poinrers  in  tbe  labeled  box  structure  bierarehy  and 
retrieve  the  eanter-x  value  of  tbe  rectangle  instance. 

In  a  diiea  reference  system,  constraints  must  use 
hardcoded  references  to  objects.  For  example,  tbe  label  in 
Rgnre  2  could  be  centered  inside  tbe  box  using  tbe  follow¬ 
ing  direct  reference  constraints: 

centar''X  •  box.c«atar-x 

eentar-y  •  box.eenter-y 

When  a  new  instance  of  Wieled-box  is  created,  the  object 
system  win  have  to  replace  all  references  to  box  with 
ttfeiences  to  the  newly  oeaed  instance  of  box. 

The  object  system  will  have  to  track  down  tbe  references 
by  manually  traversing  tbe  prototype’s  hierarchy  to  find 
where  box  is  in  relation  to  label,  (tbe  relation  is  go  to 
label’s  parent,  which  is  labeled  box,  tben  to  labeled  box’s 
first  child,  which  is  box),  tben  nse  tbe  same  traversal  in  tbe 
instance’s  ttieraxcby  to  find  the  appropriaie  reference  to  tbe 
newly  created  instance  of  box.  Thus  it  is  mucb  simpler  and 
tnore  efficient  to  implement  copying  and  instancing  opera¬ 
tions  in  indirect  reference  systems  than  in  direct  reference 
systems. 

3JS  Programming  by  Example 

Indirect  ttfeience  constraints  make  it  easier  to  implement 
systems  that  employ  demonstrational  programming,  such  as 
tbe  gr^^iical  interactive  design  tool  Lapidary  [10].  In  a 
demonstrational  system,  a  user  draws  an  example  picture  or 
demonstrates  an  example  bebavior.  and  (ben  the  system 
creates  a  prototype  object  or  bebavior  by  generalizing  tbe 
picture  or  demonstrated  bebavior.  If  the  demonstrational 
system  uses  indirect  reference  constraints,  then  it  is  easy  to 
generalize  these  examples.  In  fact,  the  example  that  tbe 
user  draws  or  demonstrates  is  already  a  prototy^,  since  the 


object  can  be  instanced  or  copied  using  the  scbeme 
described  in  tbe  previous  section. 

In  Figure  3.  a  designer  is  using  Lapidary  to  create  a  boxcs- 
and-airows  editor.  The  designer  has  drawn  an  example 
picture  in  which  (be  arrows  are  attached  to  tbe  center  of  the 
boxes  they  connect.  Lapidary  represents  tbe  constraints  of 
the  line  internally  as  indirect  reference  constraints: 


Fignrc  3. 

Aa  example  picture  dcmonsnating  that  tbe  endpoints  of 
•n  airow  should  be  attached  to  the  centers  of  the  boxes 
it  connects.  An  interface  builder  will  generalize  this 
allow  into  a  prototype  that  can  connect  any  pair  of 
boxes. 


endptl  •  ■•If.froei-ohj  .center 
eodpea  •  self. to- obj .center 
froei-obj  •  boxl 
to-obj  •  box2 

The  designer  can  save  tins  arrow  and  tbe  application  can 
use  it  as  a  prototype.  Wfaen  the  boxes-and-arrows  editor 
creates  instances  of  this  arrow,  it  stores  pointeis  to  tbe  ap- 
profniate  boxes  in  tbe  from-obj  and  to-obj  variables, 
and  tbe  constraints  automatically  attach  tbe  endpoints  of 
the  arrow  instance  to  tbe  centers  of  the  boxes.  Tbe  applica¬ 
tion  does  not  need  to  know  anything  about  the  constraints, 
soucture,  or  graphics  of  tbe  line.  Tbe  constraints  on  the 
endpoints  could  connect  centen  to  centen,  right  sides  to 
left  sides,  or  even  use  a  complex  fomula  that  computes  the 
nearest  sides  and  tries  to  avoid  crossing  other  lines. 

3.4  Abatnct  Spndfication  of  Layouts 

lodiiect  reference  constraints  facilitate  the  specification  of 
layouts,  independently  of  tbe  objects  to  be  layed  out  For 
example,  a  designer  might  want  to  specify  that  a  genenc 
feedback  object  should  appear  over  a  selected  object.  The 
actual  type  of  feedback  used  might  depend  on  the  size  of 
the  selected  object  and  tbe  type  of  tbe  selected  object.  As 
another  example.  Humanoid  (181  and  lade  (20|  allow  a 
designer  to  define  constraint-based  rales  that  describe  the 
general  layout  of  dialog  boxes  in  terms  of  the  generic  parts 
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of  a  dialog  box,  sucb  as  a  tide,  a  body  tbat  cootaios  tbe 
items  of  tbe  dialog  box,  an  OK  button,  and  a  cancel  button. 
One  can  tben  apply  tbe  niles  to  different  dialog  boxes,  ir¬ 
respective  of  tbe  widgets  tbat  fill  tbe  roles  of  tbe  different 
pans.  For  example,  staring  tte  following  coostnint  on  tbe 
X  co(»dinate  of  tbe  OK  buttoo  will  force  tbe  button  to  be 
placed  10  pixels  to  tbe  ri^t  of  the  dialog  box's  title, 
regardless  of  wbicb  widget  is  used  for  tbe  title  or  tbe  OK 
button: 

•  Mir ■paraDt.tit.l*. right  *  10 

U  Simulations 

Simulatitms  often  require  objects  to  move  snootbly  be¬ 
tween  various  points  of  tbe  display.  For  example,  sort 
animatioos  dK>w  objects  moving  around  in  linked  li^  or 
arrays,  navigation  systems  move  objects  around  transpor¬ 
tation  ccciidors,  and  manufacturing  systems  route  objects 
tbrougta  tbe  machines  on  a  factory  floor.  Indiroa  reference 
constraints  model  this  mocioa  by  using  variables  to  refer¬ 
ence  tbe  beginning  and  tatget  positions. 

For  example,  suppose  we  want  tbe  canon  in  Hgure  4  to 
glide  flora  statioo  A  to  station  B  as  if  it  were  on  a  conveyor 
belt  Tbis  could  be  done  by  writing  a  set  of  constraints  that 
inteipoiate  tbe  canon’s  petition  bued  on  a  tuner  and  the 
stadoos'  positions: 


(c) 

Figiire4. 

An  assembly  line  with  stations  connected  by  a  conveyor 
belt.  A  canon  should  be  centered  above  the  station  that 
is  cunently  processing  it  (a),  and  canons  should  move 
smoothly  from  one  station  to  the  next  (b)  and  (c). 


time  •  0 

x-dlsxance  -  self  .to-st.at.loo .canter- x 


-  sair . f ron-statlon . ceotcr-x 
center-x  «  self . fron-statloo .caotar-x 

-  (self . x-dlstanca  *  self.tina) 
to-atation  -  atation-b 
rroat-atatioD  -  atatioa-a 


X -distance  computes  tbe  distance  between  tbe  old  and 
new  stations,  and  ceotar-x  contains  tbe  current  x  posicton 
of  tbe  carton.  As  tbe  afqtlication  program  increments  time 
flam  0  to  1,  tbe  carton  moves  smoothly  between  its  old  and 
new  assembly  station.  To  prepare  for  tbe  next  step  of  tbe 
animation,  tbe  application  resets  tbe  timer  to  0,  stores  su- 
tiOD  B  in  from- station,  and  stares  a  new  station.  C.  in 
to*atatlon. 

4  Porformanca  and  Implamentation  Advantages  of 
Indirect  Reference  Constraints 

Tbe  generalization  of  constraints  using  pointer  variables 
can  improve  tbe  efficiency  of  an  a{^lication  by  reducing 
the  number  of  constraints  and  objects  it  uses,  r^ucing  the 
size  of  tbe  constrainu  it  uses,  and  reducing  tbe  number  of 
constraints  that  it  must  dynamicaUy  create  and  delete.  In¬ 
direct  reference  constraints  also  make  it  easier  for  tbe  con¬ 
straint  system  to  maintain  one  rather  than  multiple  copies 
of  a  constraint  and  make  it  easier  to  statically  compile  the 
constraints. 

Stonge  improvements  come  in  two  foims.  Fust,  by  allow¬ 
ing  objects  to  be  constrained  to  many  different  objects,  in¬ 
direct  reference  constraints  may  significantly  decrease  the 
mimber  of  objects  which  an  applicabon  creates.  For  ex¬ 
ample,  suppose  a  feetfiiack  c^j^  should  bigblight  tbe  cur¬ 
rently  sele^  item  in  a  menu,  as  in  Figure  I.a.  If  direct 
reference  constraints  are  tbe  only  constraints  available,  tbe 
designer  may  create  a  separate  feedback  object  for  each 
menu  item,  since  the  consttaints  wiP  bind  each  feedback 
object  to  exactly  one  item.  However,  as  noted  in  Section 
3.1.  indirect  reference  constraints  allow  a  feedback  object 
to  highlight  any  menu  item,  and  thus  one  feedback  object 
suffices.  Second,  indirect  reference  constraints  can  be  writ¬ 
ten  much  more  compactly  and  elegantly  than  direct  refer¬ 
ence  constraints.  Returning  to  tbe  feedback  example,  a 
clever  designer  who  is  waking  with  direct  reference  con¬ 
straints  might  be  able  to  use  only  one  feedback  object  by 
defining  constraints  wbicb  reference  every  objea  in  a  menu 
and  describe  bow  tbe  feedback  object  should  bigblight  each 
menu  item.  For  example,  to  implement  the  feedback  object 
in  Figure  l.a.  tbe  designer  might  write  tbe  following  con¬ 
straint  to  define  the  left  side  of  tbe  feedback  object: 

fMdbAck.laft  •  CISC  month 

*Janua--7';  Jan.  left 

"February' t  Feb. left 

"December*:  Dec. left 

where  month  is  a  string  variable  containing  the  currently 
selected  month. 

However,  this  soludoo  has  four  drawbacks: 

•  Non-modular  <nd  Inelegant:  If  tbe  designer 
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adds  a  new  menu  item,  tbe  designer  must  also 
lemember  to  modify  the  coostnints  ui  tbe 
feedback  object 

•  Space:  Tbe  constraint  nnist  have  twelve 
separate  conditions  and  actions,  which  causes 
tbe  code  to  occupy  a  considenble  amount  of 
space  at  runtime.  Also,  12  dependency 
pointers,  one  for  each  object  must  be  main¬ 
tained  by  tbe  constriiat  system. 

•  Eflldeocy:  Tbe  constraint  depends  on  all 
twelve  objeos.  If  one  object  changes,  even  if 
it  is  not  the  cunently  selected  object  the  con¬ 
straint  must  be  reevaluated. 

•  Dynamic  Sets:  This  ledmique  only  works  for 
static  sets  of  objects,  since  tbe  obj^  must  be 
hardcoded  in  the  constraint  It  cannot  be  used 
to  describe  dynamic  sets  of  objects,  such  as 
tbe  objects  in  tbe  drawing  wiiKiow  in  Rgure 
l.b. 

Indirect  reference  constraints  suffer  from  none  of  these  dis¬ 
advantages.  Tbe  corresponding  indirect  reference  con- 
straiiii  would  be: 

fMebACk.lare  •  aalf  .obj-ovar.l«rt 

wbere  ob  j  -  over  is  a  pointer  to  tbe  selected  menu  item. 

This  constraint  is  both  cooqtact  and  modular.  Tbe  designer 
can  add  cs  delete  items  the  menu  without  worrying 
about  the  effea  of  the  change  on  tbe  feedback  object  It 
occupies  less  space  than  tbe  corresponding  direct  reference 
constraint  and  requires  only  two  depeiKlency  pointen,  one 
to  the  variable  obj*ov«r  and  one  to  the  sdected  menu 
item.  It  depends  only  on  tbe  obj-over  vatiabte  and  tbe 
currently  selected  menu  item,  so  it  will  only  be  reevaluated 
when  absolutely  necessary.  Rnally,  this  type  of  constraint 
can  handle  dynamic  sets  of  objects.  If  additional  items  are 
added  to  the  menu,  the  constraint  automatically  deals  with 
them  without  having  to  be  rewritten. 

The  efficrency  advantage  of  indirea  reference  constraicts 
derives  in  part  from  tbeir  storage  advantage.  Fewer  con¬ 
straints  means  fewer  constraints  to  solve,  and  thus,  less 
woti:  for  an  equation  solver.  For  example,  a  constraint 
solver  that  employs  eager  evaluation  might  take  only  one 
fifth  the  time  to  set  up  tbe  feedback  for  a  five  item  menu 
using  indirect  reference  constraints  iustead  of  direc  refer¬ 
ence  constraints,  because  tiiere  are  only  one  fifth  as  many 
constraints  to  solve. 

Efficiency  advantages  also  arise  because  1)  an  object  sys¬ 
tem  does  not  bave  to  locate  and  rq^Iace  direct  references; 
and  2)  fewer  constraints  have  to  be  dynamically  created 
and  destroyed.  Tbe  search  and  replace  issue  was  discussed 
tn  section  3.2.  To  illustrate  the  reduction  in  dynamically 
created  and  destroyed  constraints,  consider  the  constniction 
of  a  menu  using  dirca  reference  constraints.  It  may  be 


unpractical  from  a  storage  standpoint  to  maintain  one  feed¬ 
bag  object  for  each  item.  Thus,  tbe  application  may  main¬ 
tain  only  one  feedback  object  and  destroy  tbe  old  con¬ 
straints  and  create  new  constraints  each  ume  tbe  feedback 
moves  to  a  new  item.  Tbe  overhead  involved  in  destroying 
and  creating  these  constraints  can  be  avoided  if  mdireci 
reference  constraints  are  used. 

Indirect  reference  constraints  also  simplify  tbe  constniction 
of  tbe  coQstraint  systsa  First,  tbe  formula  for  an  indirect 
reference  coostiaint  can  be  stored  io  a  prototype  and  in¬ 
stances  of  tbe  prototype  can  maintain  pointen  to  tbis  for¬ 
mula.  Thus,  many  instances  of  a  prototype  constraint  can 
be  created,  but  tbe  formula  is  created  only  once.  Second, 
tbe  parameten  to  a  constraint  are  implicitly  declared  by 
pointer  variables,  so  the  constraint  system  can  statically 
compile  constraints  by  wrapping  a  function  header  around 
them.  This  considerably  simplifies  implementing  a  con¬ 
straint  system  in  an  existing  general-purpose  language.  For 
example.  Garnet  constramts  can  be  arbitrary  Li^  code. 
Direct  reference  systems  typically  also  maintain  only  one 
copy  of  a  constraint  and  statically  compile  it.  However,  to 
accomplish  this,  they  require  tbe  user  to  write  tbe  constraint 
as  a  function,  complete  wiih  parameters  denoting  the  direct 
references,  or  else  pane  tbe  constraint  to  determine  the 
direct  references.  However,  we  have  discovered  that  users 
find  it  sritating  and  cumbersome  to  have  to  define 
parameten  for  constraints.  For  example,  it  is  much  more 
elegant  and  compact  to  write 

feedback. left  -  »elf .obj-over .left 
than  to  write 

constraint  left-ali^n  (obj)  (  obj . lafr  ) 
feedback .left  -  left-ali^ncself . obj -over) 

Similarly,  i!  can  be  quite  difficult  to  write  a  parser  to  search 
through  each  constraint  and  locate  the  direct  references. 

$  Implementation 

Tbe  algorithms  for  implesnentiog  indirect  reference  con¬ 
straints  build  on  tbe  algorithms  for  implementing  dirca  ref¬ 
erence  consiraints. 

5.1  Lazy  Evaluation 

A  variation  of  nullificatioo/reevaluation  algorithms  can  be 
used  to  handle  indirea  reference  coastraiots. 
NuIiiTication/teevaluation  algoritbms  repiccent  the  con¬ 
straints  as  a  directed  graph  with  nodes  represeiiting  con¬ 
straints.  and  edges  (called  dependencies)  representiiig  data 
fiowlog  from  one  coostraint  to  another  (Figure  5.a).  Vhen 
tbe  value  of  a  node  changes  (typically  a  Teaf  node  such 
as  e  or/),  all  nodes  that  directly  or  indirectly  depend  on  this 
changed  node  are  marked  out  of  date.  When  tbe  value  of  a 
node  IS  requested,  the  coostraint  tbat  computes  its  value 
starts  denuLodiog  tbe  values  of  other  nodes  on  which  it 
depends.  If  these  nodes  are  out  of  date,  they  will  recur¬ 
sively  demand  the  values  of  the  nodes  they  depend  on.  until 
eventually  nodes  are  reached  whose  values  are  up  to  date, 
at  which  pumt  the  constraints  can  coirgiutc  their  value  and 
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leam  (13. 6].  For  extople. »  ppoae  (bat  node  t  ii  changed 
ia  Hgnre  5.  Tbe  lazy  evalnatw  wiB  madt  (be  nodes  b.  d, 
and  a  aa  out  of  dale  ^guit  3.b).  If  tbe  vabie  of  node  a  is 
(ben  requested,  a  will  demand  tbe  value  of  d.  d  is  out  of 
date  so  it  demands  tbe  values  of  <  and/,  both  of  wbicb  are 
up  to  date,  cospittes  its  own  value,  tnaiks  itself  up  to  date, 
and  reninu  itt  vabie  w  a.  a  then  demands  tbe  value  of  c 
wtoeb  is  up  to  date,  computes  its  own  vabie,  mrti  itself  up 
to  due,  and  retuns. 

l^tailificatioi^reevaltatioa  algontbms  were  originally  con- 
stnacted  wdb  tbe  asnmpdon  that  tbe  edges  in  tbe  graph 
remain  static  wtnle  tbe  constraint  solver  is  evabating  tbe 
grapb.  However  indiieci  reference  cooscaiuu  can  cause 
tbe  grapb  to  dynanacally  change  as  tbe  coostraints  are  be¬ 
ing  evaluated,  because  tbe  ponter  variables  may  change, 
causing  a  ctmsttaint  to  access  informatiaa  firom  a  different 
set  of  nodes.  For  example,  when  (be  constraint  on  node  a 
is  being  evaluated,  it  may  sent  referencing  node  b  rather 
than  node  c  (Figure  3x). 

To  handle  this  situatioo.  we  have  extended  tbe  algoiitfain  so 
that  dependencies  can  be  dyoaroicaily  created  and  deleted 
as  ti<e  constraints  are  being  evaluated.  Dependencies  are 
timestanped  so  that  if  they  are  not  used  by  a  coa«tt,>*'<t  in  a 
subsequent  evaluation,  t^  became  stale  a^d  are  dis- 
caided.  When  a  constiaint  demands  a  vanable,  tbe  con¬ 
straint  solver  either  creates  a  new  depe.  dency  between  tbe 
constiaint  and  tbe  variable  if  soch  a  dependency  tnd  aot 
already  exist,  or  else  updates  (be  time  stamp  on  tbe  depen¬ 
dency  so  that  it  matches  tbe  tim^amp  on  tbe  oonstraim  (a 
constraim  is  tune  stamped  each  time  it  is  evafaiated).  Ibe 
constraint  solver  removes  stale  dependencies  as  it  in- 
validates  constraints.  Before  following  a  dependency,  it 
checks  whether  (be  dependency’s  timestamp  matches  the 
timestamp  of  tbe  constraint  it  points  to.  If  tbe  two  times- 
tamps  disagree,  the  dependency  is  discarded.  A  beneficial 
side  effect  of  this  sebeme  is  that  coostiaints  wbicb  involve 
conditionals  dtqiend  only  on  (be  variables  toat  make  iqi  the 
conditioD  and  tbe  branch  of  tbe  condbioa  that  is  executed. 
Thus  the  number  dependency  pointeni  and  unnrortsary 
evaluatiais  are  mmimiTBd 

To  see  that  this  sebeme  wotks,  note  that  a  constiaiot  wQl 
dynamically  add  or  delete  dependencies  only  if  it  cootains 
pointers  or  cooditi<»als.  If  a  constraint  depends  on  pointer 
variables,  the  constraint  will  be  marked  out  of  date  wben 
the  pointer  variables  change  and  tbe  constraint  will  be 
reevaluated  wbco  its  value  is  next  requested.  At  this  point 
tbe  constraim  solver  will  add  edges  to  this  constraint  from 
tbe  new  set  of  nodes  it  refeieooes  (Figure  3.0.  The  depen¬ 
dencies  to  variables  that  are  not  requested  by  tbe  constraint 
on  Ibis  evaluatimi  will  become  stale  and  be  removed  the 
next  tuiK  these  dependencies  are  examined.  Thus  ibe  con¬ 
straint  will  demand  tbe  values  of  tbe  correct  set  of  nodes 
and  will  obtain  tbe  cmiect  result. 

In  the  case  of  a  conditional,  tbe  branch  or  branches  of  the 
conditional  that  were  ignored  during  the  previous  evaiua- 


Qoo  of  tbe  consttaim  will  only  have  to  be  cvaiuaied  tf  tbe 
coodiboa  itself  changes.  Sina  the  constnunt  tkpends  oo 
Ibe  varubles  ui  this  coodibon,  it  will  be  marked  out  of  date 
when  one  of  these  variables  changes  and  wtlJ  be  autsanau- 
cally  reevaiuated  (of  course  it  will  also  be  teevabuted  if 
mie  of  tbe  variables  in  tbe  tnaneb  tb«  was  last  executed  is 
changed).  Again,  (be  coosirairu  solver  will  add  depen¬ 
dency  edges  to  this  consttaim  from  tbe  new  set  of  variables 
it  references  in  wfoebever  brmefa  is  executed  and  remove 
edges  that  fmarante  from  vari^les  in  tbe  prevsoosJy  ex- 
eented  bnneb.  Thus  coostaims  with  condibonais  will  al¬ 
ways  be  evaluated  coocctly. 

S.2  Eeger  Evniuetlon 

Our  eager  evabiatioo  algorithm  uses  a  variabao  of  an  eager 
evaluator  developed  by  Roger  Hoover  [4].  Like  tbe  lazy 
evaluatnr.  this  algoritto  makes  use  of  dataflow  graphs. 
However,  it  assigns  piiocibes  to  tbe  nodes  in  the  gnpb. 
indicating  tbe  nodes  lelabve  positioa  to  topoiogicai  otder 
(Figure  6a).  When  a  node  changes  vafoe.  all  itt  immediate 
successors  are  added  to  a  pnuity  queue  based  on  their 
'  ..  When  tbe  evaiaatar  starts  executing,  it  removes 
Bte  lowest  piiority  node  from  tbe  queue  and  evaloaies  it 
By  evahiat^  tbe  lowest  priority  node  in  tbe  quene.  tbe 
evaloaior  ensures  that  tbe  values  of  all  nodes  that  tbe  coo- 
stiaint  associated  with  das  node  may  request  are  up  to  date. 

1:  3ie  Hoover  algoriibEQ.  tbe  pnoribes  are  maimamed  to  an 
ordered  list  and  each  node  in  tbe  dasaflow  gnpb  points  to 
one  of  these  prionties.  Comparisons  between  prionbes  can 
be  perfocned  in  (3(1)  lime  and  insertions  of  new  prionbes 
can  be  arcomplisbed  in  amortued  0(1)  bme.  Wben  an 
edge  is  added  to  a  dataflow  graph,  tbe  algoritfam  checks 
whether  tbe  piiotity  of  the  source  node  is  greater  than  or 
equal  to  tbe  poority  of  tbe  desbnatioo  node  (data  flows 
frm  (be  source  node  to  the  destination  node;  for  example  e 
is  tbe  source  node  and  A  is  tbe  destiiutioD  node  for  tbe  edge 
that  coonects  these  nodes).  If  the  ptioiities  are  out  of  aider, 
tbe  algorithm  follows  ifae  soccessors  of  tbe  desbnaboo  node 
transitivdy  until  it  reaches  nodes  whose  priority  oumbers 
are  greater  than  tbe  priority  of  tbe  source  node  (tbe  Hoover 
algorithm  will  also  follow  predecesson  of  tbe  source  node; 
however,  to  save  space  we  do  not  mainnin  backpointers 
and  thus  we  cannot  search  backward  frtxn  nodes).  These 
nodes  are  termed  boundary  nodes.  The  algorithm  works 
back  from  these  boundary  nodes  and  assigns  lO  the  inter¬ 
mediate  nodes  new  piiority  numbers  that  are  between  tbe 
priority  numbers  of  tbe  source  and  boundary  nodes.  If  it 
runs  out  of  existing  priority  numbers,  it  creates  new  oires 
by  inserting  records  imo  tbe  ordered  list  directly  after  the 
record  associated  with  tbe  priority  number  of  (be  source 
node. 

For  example,  suppose  a  dependency  from  node  d  to  /  is 
added  in  Figure  6.b.  Node  d  has  pnority  2  while  node /has 
priority  1  so  tbe  nodes  are  out  of  order.  Tbe  algorithm  goes 
to  noifo  g.  wbicb  has  a  priority  of  Z  and  then  to  node  h. 
which  has  a  priority  of  3.  Since  this  is  greater  than  node  cTs 
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(1)  (b)  (c) 

Figures. 

(a)  Constnints  an  lepnaented  u  aodaa  in  a  dineted  giaph.  The  edgea  rejacacnt  dau  cmpaud  by  a  consvaiot  chat  another 
conamim  uaaa.  (b)  The  gny  noda  wpraieiu  nodea  autlud  out  of  date  when  node  *  ia  changed,  (c)  Node  a  now  depends  on 
node  b  rather  than  node  c. 


(a)  (b)  (C) 

Figures. 

(a)  Nuinben  are  assigned  to  nodes  according  to  the  order  in  which  (hey  arc  evaluated.  Nodes  cannot  be  evaluated  until  all  their 
predecessors  have  been  evaluated.  Darkened  nodes  represent  evaluated  nodes.  Nodes  d  and  /are  leady  for  evaluation,  (b)  Node  / 
now  depends  on  node  d  as  well  as  node  c.  (c)  Nodes  /and  g  must  be  renumbered  to  make  th^  priorities  agree  with  their  position 
in  topological  order. 


priority,  tbe  search  stops  here  and  node  h  becomes  a  bound¬ 
ary  noth:.  In  this  case  there  are  is  one  priority,  2.5,  between 
2  and  3  in  the  pnonty  list,  so  the  algwithm  assigns  this 
priority  to  node  g}  At  this  point  the  algorithm  runs  out  of 


^e  are  usaig  raaioaal  numbers  for  iOusirative  purposei  only.  The 
lecal  ajgontfain  for  naimaining  the  ordered  list  lues  only  iniegen  aid 
does  some  reordering  to  ensuie  that  only  integers  are  used. 


existing  priorities,  so  it  inserts  a  new  one  in  the  oidered  list 
aad  assigns  it  to  node /'(Figure  6.c). 

The  Hoover  algorithm  assumes  that  dataflow  graphs  cannot 
change  once  constraint  evaluation  begins,  so  the  reoidenng 
scheme  and  the  evaluator  can  be  invoked  in  sequence. 
However  indirect  lefeience  constraints  may  cause  the  edges 
of  the  graph  to  change  during  constraint  evaluauon.  Thus 
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the  aimbm  asstsoed  to  tiie  nodes  may  becooie  iocancct 
and  face  ao  etpiadoo  to  be  evaluated  ptematmtly.  To 
oveicone  tins  dtCBcnlty.  we  have  talcea  tbe  approKb  of 
dynamically  opdaimg  tbe  tt^logical  order  each  ome  the 
fiapb  cbaages.  and  evaluaiing  nodes  according  to  this 
levised  topological  order.  Is  otber  words,  the  reordeting 
algaridmi  and  the  consoaint  evaluator  are  interleaved. 
Dependencies  are  dynamcally  created  aixi  deleted  in  tbe 
same  way  as  in  tbe  1^  evalnadoo  algorithm. 

The  time  complexity  of  this  algoiittm  depends  on  the  Dum' 
ber  of  reorderings  and  the  time  teqniied  by  each  leordering. 
Assnmiag  a  bomded  nnmba  of  variables  per  equation,  a 
leasonable  aisomption  for  constraints  in  graphical  inter- 
Glees,  a  reordering  lequries  0(k)  time  where  Jt  is  tbt  mao- 
ber  of  nodes  that  must  be  reordered  (Hoover’s  algorithm 
has  an  additional  log  factor  m  tbe  ttmoiog  time  sinoe  it  uses 
a  priority  qnene  to  guide  ttt  forward  and  badcwaid  search¬ 
ing;  however  this  forward  and  backward  searching  may 
reorder  fewer  nodes  than  our  algorithm,  thns  offsetting  tbe 
log  factor).  AssnmiDg  there  are  n  nodes  in  tbe  graph,  tbe 
worst  case  ramting  time  of  the  algorithm  is  0(dn)  where  d 
is  tbe  mmber  of  dynamically  added  edges.  As  with  most 
inciemental  algorithms,  this  worst  case  ramimg  time  is  mis- 
ieadtng,  since  most  node  evaluations  do  not  trigger  a  teor- 
dering  and  most  leorderings  do  not  visit  all  n  nodes, 
fiideed.  lesnltt  based  on  preliminary  testing  of  tbe  algo¬ 
rithm  suggest  that  pointer  vaiiabies  typically  do  one  of  two 
things:  1)  they  shiA  between  nodes  whose  priority  numbers 
are  identical,  thus  cansing  no  reordering  to  oocur  or  2)  they 
shift  between  a  fixed  set  of  nodes,  and  once  they  have 
shifted  to  tbe  highest  ttmnber  node,  reordeting  never  ocems 
again.  Tbe  former  case  arises  fteqaendy  in  smnlations 
where  an  ohjm  is  typically  moving  between  indrpendeni, 
bot  fturfy  similar  obj^  that  have  nmghly  die  same  num¬ 
ber  of  caastnina  and  tbe  latter  case  arises  fkeqoently  in 
metus  where  the  last  item  has  the  constrainti  witii  die 
highest  priority  number  (because  it. is  the  last  item  laid  out). 
T^  in  practice,  the  algorithm  qipeais  to  fairly  rqiidly 
quiesce  to  a  state  where  very  few  reorderings  oocnr  during 
constraint  evaluation. 

OtiMT  implementation  Issims 

Each  time  a  coostraim  is  evaluated,  its  value  is  cached  so 
that  tbe  next  time  tbe  constraint's  value  is  requested,  the 
consoaint  will  not  be  reevaluated  unless  ooe  of  its 
pazameten  has  changed.  Similariy  tbe  values  of  paths  can 
be  cached  to  improve  efficiency.  For  exampi^  in  the 
labeled  box  example  presented  in  Section  3X  the  label 
accessed  the  position  of  the  box  using  the  path 
(self .parent. box).  The  first  tune  this  path  is 
evaluared,  the  constraint  solver  can  cache  the  resulting 
pointer  to  tbe  box.  so  that  as  long  as  the  variables  compris¬ 
ing  tbe  path  do  not  change,  tbe  constraint  bebaves  as  a 
diiea  reference  constraint.  The  variables  on  this  path  still 
maintain  deperxiency  pointers  to  tbe  constzainL  so  that  if 
one  of  these  variables  chan^.  the  patb  can  be  reevaluated 
and  a  new  value  cached  for  it 


Anotbo'  iznplementatioa  issue  that  arises  is  what  to  do  with 
constraints  cootaining  variables  dm  are  nil  or  which  refer¬ 
ence  deleted  objects.  Tbe  two  optiom  considered  in  Garnet 
were  1)  to  destroy  the  cooftraint.  keqiing  its  previously 
comptned  value;  or  2)  to  keep  tbe  coosoaint  and  renan  its 
previously  computed  value.  Under  option  two.  the  con¬ 
straint  would  again  be  evaluated  once  all  its  variables  point 
at  valid  objects.  We  settled  on  tbe  secood  option  since,  in 
many  cares,  the  coosoaint  win  be  used  again.  Ftu  ex¬ 
ample,  feedback  objects  dm  are  invisitde  may  have  duai 
Ob  j  -oTor  variables  set  to  nil,  yet  tbe  consoaints  should  be 
mainwin<»^  10  that  they  can  coneedy  positioo  tbe  feedback 
object  once  it  4  made  visible  and  its  obj-ov*r  variable  is 
set  to  a  newly  selected  item 

6  Status  and  Future  Work 

Indiiect  reference  coosaraints  have  been  completely  im¬ 
plemented  at  a  very  low  level  hr  Ganm.  Every  layer  in 
Garnet  is  implememed  on  top  of  tbe  consaratot  system 
using  indirect  telLmce  coosoaims,  except  for  the  lowest- 
level  untyped  objea  system.  Th4  includes  tbe  graphical 
object  system,  tbe  haivtiing  oi  tbe  input,  and  an  the  widget 
libraries.  In  addition.  Garnet  has  approximaieiy  130  users 
who  have  used  indiiect  reference  constraints  to  generate 
hnndieds  of  applications. 

Garnet  cuneotly  uses  lazy  evalnation  and  a  modified  user- 
controlled  version  of  caebiog  that  evaluates  a  patb  the  first 
time  the  constraint  4  evaluated  and  then  ignores  a  if  the 
user  assmes  the  constraint  solver  that  the  path  wUl  never 
change.  On  a  SUN  Spaicstation  14^  nmning  Lndd  Com¬ 
mon  Lisp,  an  indiiea  wierencf  to  an  objea  throngfa  a  vari¬ 
able  (e^.,  Mlf  .obj-arv«r.l«ft)  requires  170 
microieconds.  whereas  a  dnea  reference  (e.g.. 
Mou-  it«ia .  left)  or  a  reference  dm  uses  a  cached  path 
lequnes  S4  nticroseceods.  If  a  constraint  does  not  have  to 
be  reevahmed,  its  pievioasly  computed  value  can  be  ac¬ 
cessed  in  19  micitnecoods,  regardless  of  whether  it  4  a 
direa  lefetenoe  or  indiiea  reference  coostraioL  Garnet's 
constraint  sotver  can  solve  indiiea  reference  constraints 
quickly  enough  id  alkw  feedback  objects  to  track  the 
mouse  in  real  time  or  to  peifons  smooth,  realtime  anima¬ 
tions.  even  in  large,  constraint-based  applicatioos.  For  ex¬ 
ample.  the  Lapidary  interaaivc  design  too!  [101  consists  of 
16()00  lines  of  Lisp  code  aixl  233(X)  constraints,  all  of 
which  are  indirea  reference  constraints,  and  is  fast  enough 
to  provide  instantaneous  feedback  to  tbe  user. 

We  have  a  working  version  of  ao  eager  evaluator  that  we 
believe  is  more  effiaeiu  than  the  current  lazy  evaluator  and 
which  should  be  implemented  in  Garnet  in  the  near  future. 
We  also  have  a  design  for  two-way  indiiea  reference  con¬ 
straint  systems.  Finally,  we  are  examining  graphical  means 
of  oaciDg  these  constraints  so  that  designen  can  debug 
them  more  easily  [12]. 
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7  Conclusions  and  Future  Work 

lodiiect  reference  constraints  allow  procedural  abstraction 
to  be  added  to  constraint  systems.  This  signincanily  ex¬ 
tends  tbe  potential  uses  of  coostiainu  in  interactive  applica¬ 
tions  by  allowing  constraints  to  express  the  dynamic  be- 
bavior  tbat  occun  inside  an  applicatioo's  window.  Tbese 
constraints  can  be  used  to  spe^  animatioas  and  feedback 
tbat  operate  over  dynamic  sets  of  objects,  implement  copy¬ 
ing  and  instancing  of  stmcnned  objects  in  prototype- 
instance  systems.  sun{diiy  the  cteation  of  prototype  objects 
from  example  objects  in  demoosaadonal  systems,  and 
abstractly  specify  layouts.  In  addition,  tbeir  programming 
style  is  simpler  and  more  effective  than  conventional  con- 
stiaims.  they  improve  tbe  efBciency  of  applicadoos,  and 
they  decrease  an  application’s  storage  drrnands.  Because 
of  tbeir  flexibility  and  ease  of  use.  indirect  reference  con¬ 
straints  bave  pennined  a  compretaensive  nser  interface 
toolkit  to  be  built  for  tbe  first  tiine  on  top  of  a  constraint 
system.  This  represents  an  important  step  toward  the 
development  of  a  general-purpose,  constraint-based,  inter¬ 
active  progransning  language. 
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ABSTRACT 

Most  programming  in  the  Garnet  system  uses  a 
declaiadve  style  that  elimiiuues  the  need  to  write  new 
methods.  One  tffi(iication  is  that  the  interface  to  ob¬ 
jects  is  typically  through  their  dau  values.  This  con¬ 
trasts  significantly  with  other  objea  systems  where 
writing  methods  is  the  central  mechanism  of  program¬ 
ming.  Four  features  ate  combined  in  a  unique  way  in 
Carnet  to  make  diis  possible:  the  use  of  a  prototype- 
instaiKe  object  system  with  structural  inheritance,  a 
retained-object  model  where  most  objects  persist,  the 
use  of  constraints  to  tie  the  objects  together,  and  a 
new  input  model  that  makes  writing  event  handlers 
unnecessary.  The  result  is  that  code  is  easier  to  write 
for  programmers,  and  also  easier  for  tools,  such  as  in¬ 
teractive.  direct  manipulation  interface  builders,  to 
generate. 

KEYWORDS:  Object-Oriented  Programming, 
Prototype- Instance  Model.  Toolkits.  Declarative  Pro- 
granuning.  Constraints.  Input,  Garnet. 
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1.  Introduction 

Over  the  last  three  yean  of  using  the  Garnet  system  to 
create  dozens  of  large-scale  user  inierfaces.  we  have 
observed  that  the  style  of  programming  in  Garnet  is 
quite  different  from  that  in  conventional  object- 
oriented  systems.  In  Garnet.  progFairuners  combine 
pte-defined  objects  into  collections,  use  constraints  to 
define  the  relationships  among  them,  and  then  attach 
pre-defined  “Interaaor”  objects  to  cause  the  objeos 
to  respond  to  input.  The  result  is  a  declarative  style  of 
programming  where  the  programmer  rarely  writes 
methods.  Furthermore,  the  interface  to  (Ejects  is 
usually  through  direct  accessing  and  sening  of  data 
values,  rather  than  through  methods. 

The  feanires  of  the  Garnet  object  system  have  been 
motivated  by  the  overall  goal  of  the  project:  to 
provide  high-level,  interactive,  mouse-based  tools  for 
rapidly  prototyping  and  creating  graphical,  highly- 
interactive,  diiect  manipulation  programs.  Because  of 
the  emphasis  on  rapid  creation  and  easy  editing,  we 
have  chosen  to  make  the  object  system  completely 
flexible  and  dynamic.  Since  the  interactive  tools  need 
to  be  able  to  generate  code  for  the  interface  and  then 
read  the  code  for  later  editing,  it  is  easier  to  generate 
high-level,  declarative  specifications.  Because  much 
of  the  look  and  the  dynamic  behavior  in  Garnci  can  be 
specified  by  supplying  parameters  to  pre-defined  ob¬ 
jects,  it  is  easier  for  inieraaive  tools  to  display  these 
options  in  dialog  boxes  or  intelligently  guess  them 
using  dcmonstrational  techniques. 
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In  order  to  achieve  these  goals,  we  have  made  a  num¬ 
ber  of  interesting  design  decisions  which  contribute  to 
Garnet’s  unique  piogranuning  style.  First.  Garnet 
uses  a  prototype-instance  model  rather  than  the  more 
popular  class-instance  model.  In  a  prototype-instance 
model,  there  is  no  distinction  between  instances  and 
classes;  any  instance  can  serve  as  a  “prototype”  for 
other  instances.  Garnet’s  model  is  unique  in  that  it 
supports  structural-inheritance.  This  means  that  when 
aprototype  object  is  a  collection  (or  “aggregate”)  of 
other  objects.  Garnet  creates  instances  of  all  com¬ 
ponents  when  the  aggregate  is  instanced.  Therefore, 
the  programmer  can  construa  complex  graphical  ob¬ 
jects  by  declaratively  listing  the  primitive  component 
objects.  It  is  not  necessary  to  write  creation  or  draw¬ 
ing  methods. 

Second,  the  objects  in  Garnet  are  usually  persistent 
and  long-term.  For  example,  the  graphics  model  re¬ 
quires  that  there  be  an  object  in  memory  correspond¬ 
ing  to  each  object  on  the  screen.  This  means  that  the 
programmer  docs  nw  have  to  deal  with  object  refresh, 
and  allows  the  toolkit  to  contain  high-level  support, 
like  selection  handles.  In  many  other  systems,  a 
single  object  can  be  used  like  a  stamp-pad  and  drawn 
in  multiple  places  on  the  screen. 

Third,  constraints  can  be  used  to  declare  the  relation¬ 
ships  among  the  objects.  Constraints  in  Garnet  are 
tightly  integrated  with  the  object  system,  so  that  any 
slot  of  any  object  can  have  a  constraint  which  cal¬ 
culates  its  value.  The  result  is  that  the  interface  to 
objects  is  usually  through  data  values  which  arc 
directly  accessed  and  set,  rather  than  through 
methods.  Constraints  ,rc  used  to  propagate  the 
changes  appropriately. 

Fourth,  Garnet  incorporates  a  novel  input  model, 
which  provides  standard  objects  called  “Intcractors” 
to  handle  the  most  popular  direct  manipulation  be¬ 
haviors.  This  is  based  on  the  Model-View-Controller 
idea  from  Smalltalk  [8|,  where  the  Interactors  cor¬ 
respond  to  the  controllers.  In  Garnet,  however,  unlike 
in  Smalltalk  and  other  implementations  of  this  idea, 
the  programmer  rarely  writes  new  Interactor  methods. 
Instead,  the  programmer  atuches  an  instance  of  a  pre¬ 
existing  Interactor  object  to  the  graphical  objects 
using  constraints,  and  declaratively  specifies  any 
necessary  controlling  parameters  for  the  Interactor. 


This  paper  discusses  these  aspects  of  Garnet,  and 
shows  the  advanuges  of  the  Garnet  style  of  program¬ 
ming.  Even  though  conventional  wisdom  for  object- 
oriented  programming  is  that  writing  methods  is 
“good”  and  exposing  the  objects’  dau  is  “bad.”  we 
show  that  the  Garnet  style  is  just  as  modular  and 
provides  just  as  much  information  hiding.  Further¬ 
more.  there  is  some  evidence  that,  at  least  for  user 
iiuerface  programming,  it  is  more  effeaive. 

Garnet  is  a  comprehensive  user  interface  development 
environment  in  Lisp  for  X/11.^  It  is  in  the  public 
domain  and  is  freely  available.  Currently,  over  30 
projects  around  the  world  are  using  the  system 
regularly.^  The  system  contains  a  number  of  features 
that  make  it  well-suited  for  creating  graphical  user  in¬ 
terfaces.  Unlike  other  toolkits  which  primarily  supply 
widgets.  Garnet  is  specifically  designed  to  cover  all 
aspects  of  user  interface  programming,  especially  the 
insides  of  application  wirxiows.  While  them  have 
been  a  number  of  papers  about  Garnet  (17]  and  its 
componcrus  [23. 15, 24. 19],  this  is  the  first  paper 
about  the  programming  style.  For  a  complete  discus¬ 
sion  of  programming  in  Garnet,  see  the  mference 
manual  [20]. 

2.  Related  Work 

In  the  terms  of  the  “Treaty  of  Orlando”  [22],  the 
Garnet  objea  system  is  a  prototype-instance  model 
with  dynamic,  implicit,  per-object  sharing.  It  is 
dynamic  because  the  inheritance  can  be  changed  at 
any  time,  implicit  because  objects  inherit  from  their 
prototypes  and  you  cannot  explicitly  declare  how 
slots  are  inherited  (except  by  using  constraints),  and 
per-object  because  there  is  no  such  thing  as  classes. 
The  “templates”  (prototypes)  arc  entirely  "non- 
strict.”  which  means  that  an  instance  can  gain  or  lose 
slots  at  any  time.  These  features  make  Garnet  much 
like  SELF  [5]  and  other  prototype-instance  systems 
[9].  However,  unlike  SELF.  Garnet  rarely  uses  mul¬ 
tiple  inheritance  (although  it  is  allowed),  and  we  have 
integrated  a  constraint  solving  mechanism  with  the 


'Disptiy  Postscript  and  Maciniosli  venions  are  in  progress. 

^You  can  get  Garnei  by  anonymous  FTP  from 
a .  qp .  cs .  emu  .  edu.  Orange  to  the  directory 
/uar/qarnec/qarnet/  (note  the  double  garnet's)  and 
retrieve  README  for  intmicdons.  Or  you  can  send  electronic 
mail  toqatnet0cs  .emu  .edu. 
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objca  system.  Another  imponant  difference  is  that 
Garnet  encourages  programmers  to  directly  access 
and  set  slots  of  objects,  whereas  SELF  prevents  this 
and  only  provides  methods. 

Many  systems  have  used  constraints  as  part  of  an  ob- 
jea  system  [3],  but  none  is  as  general-purpose  or 
fully-integrated  as  Garnet  Garnet  is  also  the  first  sys¬ 
tem  to  introduce  pointer  variables  into  constraints 
(where  the  objects  referenced  by  the  constraint  can 
change).  The  first  integrated  constraint  and  object 
system  was  ThingLab  [2],  which  supported  multi-way 
constraints.  ThingLab  was  also  a  prototype-instance 
object  system.  Apogee  [7]  and  Growfl]  are  more 
closely  related  to  Garnet  in  goals,  since  they  are  user 
interface  toolkits.  Also,  like  Garnet,  they  implement 
one-way  constraints.  Neither,  however,  uses  con¬ 
straints  as  the  primary  mechanism  for  information 
passing,  so  they  both  make  extensive  use  of  metlKXls. 

As  was  mentioned.  Garnet's  input  model  is  based  on 
the  Model- View-Controller  idea  from  Smalltalk  [8]. 
Other  attempts  to  capture  interaaive  behaviors  in¬ 
clude  the  model  used  by  graphics  standards,  such  as 
PHIGS.  GKS.  CGI,  CORE.  etc.,  which  identifies  five 
or  six  basic  input  types  (e.g.,  locator,  stroke,  valuator, 
choice,  pick  and  string  for  PHIGS).  This  is  based  on 
a  model  by  Foley  and  Wallace  [6].  Unfortun^ely, 
this  model  has  proven  unusable  for  modem  user  inter¬ 
faces  [12]. 

The  current  object  and  constraint  system  is  a  complete 
redesign  and  rewrite  of  the  Coral  system  [23],  Coral 
was  implemoited  in  CLOS,  but  was  abandoned  be¬ 
cause  it  was  too  slow  and  inflexible  in  practice.  Like 
Garnet,  Coral  provided  a  declarative  syntax  for  ob¬ 
jects  and  constraints,  but  it  was  not  possible  to  modify 
objects  once  they  had  been  created.  Coral  used  a  con¬ 
ventional  class-instance  model,  rather  than  the 
prototype-instance  model  we  now  use.  It  also  re¬ 
quired  that  the  constraints  be  parsed  to  search  for  ob¬ 
ject  references,  which  limited  the  kinds  of  constraints 
that  could  be  written.  The  current  Garnet  constraint 
system  docs  not  need  to  parse  constraints  because  it 
dynamically  determines  the  dependencies  when  the 
constraint  is  evaluated.  Coral  did  not  provide  for  ar¬ 
bitrary  pointer  variables  in  constraints  like  Garnet 
does  now,  and  it  used  active  values,  which  we  have 
found  to  be  unnecessary  in  Garnet  with  fully  func¬ 


tional  constraints.  Coral  had  a  spccial-pwrposc 
mechanism  for  constraints  over  lists  of  objects,  such 
as  the  items  of  a  menu.  For  example,  you  could 
specify  a  constraint  for  the  top  of  the  first  item  and  a 
different  constraint  for  the  rest  of  tlw  items.  This  is 
not  needed  in  Garnet  due  to  the  support  for  arbitrary 
code  in  constraints  (you  can  just  use  Lisp’s  looping 
facilities).  The  create  routines  in  Coral  were  specific 
to  each  class,  rather  than  a  generic  function  that 
would  work  for  all  classes.  Other  imponant  problems 
with  Cora]  were  that  the  declarative  technique  did  not 
suppon  changing  objects  after  they  were  created,  and 
it  was  not  available  to  interactive  editors.  Therefore, 
a  separate  procedural  mechanism  was  supplied.  In  the 
current  Gamci,  the  declarative  and  procedural 
mechanisms  have  equivalent  power. 

3.  The  Prototype-Instance  Object 
Model 

The  Garnet  object  system  implements  the  prototype- 
instance  model  (9),  and  supports  completely  dyitamic 
redefinition  of  prototypes  with  automatic  change 
propagation.  There  is  no  distirKtion  between  in¬ 
stances  and  classes;  any  instance  can  serve  as  a 
“prototype”  for  other  instances.  All  dau  and 
methods  are  stored  in  “slots”  (sometimes  called 
“fields”  or  “instance  variables”).  An  instance  can 
add  any  number  of  new  slots,  and  slots  that  are  not 
overridden  in  an  instance  inherit  the  values  from  its 
prototype.  In  fact,  the  inheritance  can  change 
dynamicaUy.  as  an  object  can  add  or  remove  slots  at 
any  time.  There  is  no  distinction  between  data  and 
method  slots.  Any  slot  can  hold  any  type  of  value, 
and  in  Common  Lisp,  a  function  is  just  a  type  of 
value.  This  allows  the  methods  that  implement  mes¬ 
sages  to  change  dynamically,  which  is  not  possible  in 
conventional  object  systems  like  Smalltalk.  The 
ability  to  dynamically  add,  delete,  and  modify 
methods  has  proven  imponant  in  graphical  interface 
builders  since  they  need  to  temporarily  insert  their 
own  methods  during  “build”  mode,  and  then  retract 
them  during  “test”  mode. 

All  objects  are  created  with  the  standard  function 
create- Instance  which  lakes  an  optional  name 
of  the  new  object,  an  optional  object  to  be  used  as  a 
prototype,  and  a  list  of  slots  and  values  that  should 
have  local  values.  Slots  that  are  not  mentioned  start 
out  using  the  inherited,  default  value  from  the 
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prototype  (which  can  be  changed  later).  Slot  names 
start  with  colons,  and  can  contain  any  number  of 
printable  chaiacteis  (e.g.,  :le£t,  :  interim- 
selected,  :obj-over).  In  the  following  ex¬ 
ample.  the  rectangle  named  my-rect  will  inherit  the 
:top,  :width,  and  :height  from  the  prototype 
rectangle: 

n^»rf  namui netoKflt  Mtriimtfrom Hotkiin. 
(crajica-inscanc*  ‘  cactangla  NIL 

(.-Cop  10)  (:lafc  10)  ;sptciffymtmtfortcmttloa. 
(:Hidt)>  20)  (:bal<jhc  2i)  (:coler  black)) 

:cnaumf-rtcluikaritiKffromrtaa»ff*. 

(eraata-lnacanca  'ny-ract  raceanqla 

(:lafc  4S)(:eolor  blua))  ; ootmdt (•>« tiaa. 

Setting  an  object's  slot  with  a  value  automatically 
creates  the  slot,  if  needed.  This  makes  it  extremely 
easy  to  associate  any  piece  of  information  with  any 
object,  since  slot  names  do  not  have  to  be  predefined. 
For  example,  the  follOMong  will  create  a  new  slot  in 
rectangle: 

(s-valua  raccanqla  :pariinacar  90) 

Because  my-rect  inherits  from  rectangle,  it  will 
also  now  have  the  new  slot 

There  is  a  ^cial  kind  of  object  in  Garnet  called  an 
“aggregate”  which  is  a  collection  of  other  objects.  A 
unique  feature  of  Garnet  is  that  whenever  an  instance 
is  made  of  an  aggregate,  Garnet  automadcaily  creates 
instances  of  all  its  components,  and  links  them 
together  appropriately.  This  “structural  inheritance” 
is  an  extremely  powerful  abstraction,  because  it  frees 
the  user  from  having  to  know  whether  an  objea  being 
instatKed  is  a  primitive  object  like  rectangle  or  a 
composite  like  button;  the  create -instance  call  is  the 
same. 

For  example,  a  button  might  be  composed  of  three 
rectangles  and  a  text  object.  The  programmer  can 
declaratively  list  these  as  part  of  a  bunon,  as  shown  in 
Figure  1.  Then,  when  the  user  creates  my-buttonl 
using  button  as  the  prototype.  Garnet  automatically 
creates  instances  of  the  three  rectangles  and  the  text. 
Of  course,  any  of  the  parts  could  themselves  be  ag¬ 
gregates.  tmd  the  instancing  would  be  applied  recur- 
sively.  Constraints  (described  below)  are  used  to 
declare  how  the  properties  of  the  components  are  con¬ 
nected. 

An  important  irmovation  in  Garnet  is  that  edits  made 
to  the  prototype  are  automatically  reflected  in  all  in¬ 
stances.  For  example,  if  the  color  of  fill-inside 


(craaca-lnscanc*  ‘ button  aqqroqota 
(: pacts 

((:top-«dq«  roctsnql*  ....)  ;  wktU  Uft  i  top  ttifts 

(:bottOB-«dq«  coctanqle  btack  nfhi  ^  bouam 

(:fill-inildd  coctanqls  ...)  ;  fny  uatrior 
(:t<b«I  toxt  ...  ;  striitf  uuidi  buttom 

(:strlnq  ‘Labdl") )  )  )  ) 

(ccasta-lnstsnca  'ny-buttonl  button 

(:Iaft  tool (; top  Sl(; ttcinq  'First')) 
(craata-lnstanca  'ny-button2  button 

(ilalt  t00)(:top  3S)(;strinq  'Sacond')  ) 
(craata-instanca  ' my-buttonl  button 

(:loft  100) (stop  6S)(:strinq  'Third')) 

(b> 

Figure  1: 

(a)  A  buoon  (shown  on  the  left)  and  some  instances  created 
from  it  (b)  The  outline  of  the  button's  aggregate  structure 
and  the  code  to  create  the  instances. 


were  changed  in  button,  it  would  automatically  also 
change  in  my-buttonl  and  all  the  other  instances 
(see  Figure  2).  More  significandy,  if  a  part  is  added 
or  removed  from  the  prototype,  then  Garnet  will  add 
or  remove  the  corresponding  object  from  all  in¬ 
stances.  For  example  if  top-edge  was  removed 
from  button,  then  the  appropriate  rectangle  would 
also  be  removed  from  my-buttonl  and  the  other 
instances.  Garnet  stores  pointers  in  each  prototype  to 
all  instances  to  support  these  operations. 

Similarly,  if  the  programmer  wants  to  create  an  object 
which  is  a  slight  modification  of  an  existing  object,  it 
is  only  necessary  to  override  the  divergent  parts.  For 
example,  the  programmer  could  have  left  the  existing 
button  prototype  of  Figure  I  unmodified,  and 
created  a  new  type  of  bunon  that  looks  like  Figure  2 
by  specifying: 

(ccvitc-lnscxnc*  'neu-bucton  button 
( : p«rts 

((:top-«dq«  ;omtt)  ;  tion't  xtaiu  lb*  lop-tdgt  rtaortfit. 

(:  (11 1 -Indd*  :modlfy 

;jtai  chaitft  ifu  fillmg-srylt  proptny. 

( : (1  111 nq-»ty 1«  llqht-qray ) ) 

t  s  .fcotMm.«d|«  mod  :tob*l  art  iMehMKgtd. 

))) 
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Figure  2: 

Whea  the  colar  oi  the  fill-inside  tectangie  is  changed 
to  light-gray  and  the  tap-edge  rectangle  is  removed  from 
the  t)uit«  prototype  in  Figioe  1,  these  changes  propagate 
autommically  to  the  instances. 


In  a  conventional  objea  system,  the  programmer 
would  insmad  be  required  to  rewrite  the  entire  draw 
method  (and  probably  the  erase  and  many  other 
methods  as  well).  In  Garnet,  only  the  spedlic  pans  to 
be  changed  need  to  be  mentioned,  and  only  in  the  ob¬ 
jea  definidoa 

A  very  significant  advanuge  of  this  technique  is  that 
it  is  possible  to  ;novide  graphical,  interactive  tools 
that  will  create  the  graphical  objects.  For  example. 
Lapidary  {IS]  allows  progiammeis  to  draw  pictures  of 
new  widgets  (like  the  buaons  above)  and  of  new 
ap^cadon-spedfic  prototypes.  The  interface  of 
Lapidary  is  much  like  a  convemional  drawing 
program  like  MacDraw.  The  programmer  can  spedfy 
which  slots  will  be  parameters  (for  the  button,  they 
might  be  the  position  and  string).  Interactive  be- 
haviois  and  relationships  among  the  components  can 
also  be  defined.  Because  all  objects  have  the  same 
structure.  Garnet  provides  a  built-in  reutine  that  wiU 
save  the  objects  to  a  file  (21  ].  The  contents  of  the  file 
is  simply  the  declarative  code  to  create  the  objects,  as 
in  Figure  1-b.  Therefore,  this  file  can  be  compiled 
using  the  standard  Lisp  compiler,  and  the  standard 
Lisp  load  routine  is  all  that  is  needed  to  read  in  the 
objects. 

Therefore,  Lapidary  can  simply  call  the  standard  save 
routine  to  write  the  created  objects  to  a  file,  instead  of 
having  to  generate  code  for  the  methods  to  create, 
draw,  and  erase  the  objects,  and  for  handling  input 
events.  When  the  application  wimts  these  graphic^ 
objects  to  appear  at  nin-dme,  it  only  needs  to  load  the 
file,  and  create  instances  of  the  prototypes  supplying 


the  appropriate  parameters.  Note  that  unlike  ocher  in- 
ceiacdve  interface  builders,  such  as  the  NeXT  Inter¬ 
face  Builder,  Lapidary  allows  the  designer  to  define 
entirely  new  objects,  not  just  choose  pre-defined  ob¬ 
jects  from  a  palette.  The  various  features  of  Garnet’s 
objea  system  make  this  much  easier  to  implement 
(21). 

Since  edits  to  a  prototype  are  refleaed  in  its  instances, 
it  is  even  possible  to  interactively  change  the  ap¬ 
pearance  of  objects  while  they  are  being  used  in  an 
application.  When  Lapidary  or  a  similar  tool  changes 
the  prototype,  all  of  the  instances  are  updated  im¬ 
mediately.  even  if  they  appear  inside  of  an  application 
that  is  currently  ninning.  This  helps  achieve  the  goal 
of  making  Garnet  useful  for  rapid  prototyping  of  in¬ 
terfaces.  since  the  designer  can  see  the  results  of  the 
edits  in  context.  In  a  class-instance  model  or  any 
method-based  objea  system,  it  would  usually  be 
necessary  to  stop  and  recompile  to  see  the  results  of 
edits. 

One  claimed  disadvantage  of  the  prototype-instance 
model  is  speed,  since  every  slot  access  and  setting 
might  require  a  search  up  the  inheritance  hierarchy  to 
find  the  slot  However,  through  implementation  tech¬ 
niques  such  as  caching,  we  have  significantly  im¬ 
proved  the  performance  of  Garnet.  Thus,  even  though 
Garnet  offers  dynamic  inheritance,  constraints,  and 
automatic  constrairtt  elimination  (explained  below),  it 
only  takes  17.9  microseconds  to  access  a  slot  (on  a 
SPARCSiation  1,  using  Allegro  Common  Lisp 
V4.0.1). 

4.  Retained  Objects 

Another  important  feature  of  Garnet’s  object  system 
is  that  most  objects  are  ’’long-term."  Unlike  other 
object  systems,  it  is  rare  in  Garnet  to  repeatedly  al¬ 
locate  and  dispose  of  objects.  Most  objects  are  used 
to  represent  application  information,  graphical  dis¬ 
plays,  or  interactive  behaviors  which  persist. 

For  examine,  all  graf^cs  use  a  "reiained-objea 
model”  (sometimes called  "structured  graphics"  ora 
"display  list").  This  means  that  for  every  graphical 
objea  on  the  screen,  there  is  a  corresponding  object  in 
memory.  Therefore,  to  make  something  appear  on  the 
screen,  the  programmer  creates  instances  of  graphical 
objects  and  adds  them  ro  a  window.  A  significant 
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diffeience  fmm  other  systems  that  supply  structured 
gnphics,  such  as  QJM  [11]  and  Interviews  [10]  is 
that  there  is  no  way  to  avoid  using  the  structured 
gr^iiics  in  Garnet:  ali  graphics  must  be  displayed  by 
attaching  instances  of  ot^cts  to  windows. 

As  an  example,  to  display  iny-buttonl  or 
,  my-zect,  the  programmer  can  create  an  instance  of 
a  window  and  add  these  objects: 

(er««c«-lnscMca  'iiy-windeH  uindoMl 

(•dd-eaapen«nc»  ay-uindew  ay^buccont  ay-ract) 

This  will  cause  the  objects  to  be  dis^dayed. 
Prototypes  can  also  be  displayed,  since  there  is  no  dis- 
tinctioa  between  prototypes  and  instances.  Therefore, 
the  button  that  says  “Label**  in  Figure  1  is  the  acnial 
prototype  for  the  instances. 

In  a  similar  way.  Interactor  objects  which  control  be¬ 
haviors  (described  below)  ate  also  allocated  and  at¬ 
tached  to  graphics.  Funhennore.  the  dau  that 
describe  the  informadon  and  state  of  the  appUcatioa 
are  often  stored  as  Garnet  objects.  Thus,  our  tech¬ 
niques  are  not  just  limited  to  the  gr^ihical  user  inter- 
foce  pan  of  the  appUcadtm. 

In  onfor  to  change  any  property  of  an  object,  it  is  only 
necessary  to  set  the  appn^ate  slot,  and  Garnet  will 
propagate  the  change  appropriately.  For  examine,  to 
change  the  string  of  my-buttonl.  you  could  use: 

(*-v«lu«  ay-bucconl  iitcinf  *N«w  Lcbbl*! 

This  is  implemented  using  a  special  demon  procedure 
that  can  be  associated  with  each  object  This  demon 
will  be  called  whenever  any  slots  of  the  objea 
^  change.  For  graphical  objects  in  Garnet,  a  built-in 
demon  is  used  which  automarically  insures  that  the 
appropriate  graphical  objects  on  the  screen  are 
redrawn.  The  graphical  update  algorithm  aaempts  to 
mirumize  the  number  of  objects  that  are  redrawn  by 
ftrst  determining  all  objects  that  change  and  all  ob¬ 
jects  that  intersea  them,  and  then  drawing  only  those 
objects  (from  back  to  ftont)  using  an  appropriate  clip- 
^g  region.  A  different  demon  is  used  for  Interaaor 
objects,  and  applications  can  supply  their  own 
demons  for  application-specific  objects,  if  necessary. 

The  advantage  of  the  retained-objea  model  is  that 
programmers  are  freed  from  many  of  the  maintenance 
tasks  they  would  have  in  most  other  systems.  There 
is  never  a  need  to  write  or  call  create,  in¬ 
itialize,  draw,  or  erase  methods.  When  a 


complex  a^lication-specific  graphical  object  is 
desired,  the  programmer  uses  the  declarative  syruax  to 
list  all  the  compottem  parts,  and  then  creates  instances 
and  adds  them  to  the  a{^ptiate  window.  Of  course, 
the  prototypes  themselves  can  also  be-  created 
dynamically  at  nin  time.  When  objects  are  to  be 
changed.  Garnet  automatically  determines  what  must 
be  redrawn.  Using  the  same  mechaiusm.  Garnet 
handles  window  scrolling  aixl  refresh  automatically. 

Of  course,  the  primitive  graphical  objects,  such  as 
rectangles,  lines  and  text,  use  draw  methods  internally 
to  displr.y  themselves  on  the  screen.  Other  internal 
methods  are  used  for  handling  refresh  and  for  asking 
objects  whether  they  are  under  the  mouse.  However, 
since  Gama  supplies  a  primitive  objea  for  each  kind 
of  drawing  operation  in  the  X  iATtndow  System,  any¬ 
thing  that  can  be  drawn  in  X  can  be  created  by  com¬ 
bining  instances  of  Garnet’s  graphical  objects.  There¬ 
fore,  the  programmer  can  simply  ocmtbine  the  built-in 
graphical  objects,  and  never  needs  to  write  new 
methods. 

Anotha  important  advantage  of  the  retained  model  is 
that  the  toolkit  can  provide  built-in  utilities  for  many 
of  the  common  ftmctions,  since  all  data  uses  a  stan¬ 
dard  structure.  For  example.  Gama  provides  a 
widget  which  displays  the  popular  square  "handles" 
around  graphical  objects  for  selection,  moving,  and 
growing  them.  This  works  because  the  handles  can 
reference  the  reuined  graphical  objects  to  know  what 
is  on  the  screen,  and  how  to  modify  them.  Similarly, 
there  are  built-in  routines  for  creating,  duplicating, 
deleting,  moving,  growing,  and  printing  objects. 
Thus,  application  developers  do  not  need  to  write 
code  for  any  of  this. 

The  primary  problem  with  the  retained  objea  model 
is  the  potential  for  enormous  space  irrefficiendes.  If 
diere  are  10,000  objects  on  the  screen,  there  must  be 
10,000  objects  in  memory  to  represent  them.  We 
have  taken  a  number  of  steps  to  overcome  this 
problem.  As  with  the  Glyphs  in  Interviews  [4],  we 
remove  unneeded  information  from  objects.  For  ex¬ 
ample.  we  can  remove  large  numbers  of  unnecessary 
constraints  (see  below).  Howeva,  unlike  Glyphs, 
each  objea  in  Gama  still  keeps  information  about 
where  it  is  located  on  the  screea  Second,  if  there  are 
a  large  number  of  nearly  identical  objects,  suctr  as  the 
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squares  in  a  bitmap  editor  ("fat  bits*’},  the  lines  in  a 
mtq>  or  mesh  (Figure  3).  or  the  dots  in  a  graph,  then  a 
"virtual  aggregate"  can  be  used  that  just  pretends  to 
create  an  objea  for  each  graphic.  The  programmer 
provides  a  prototype  object,  and  the  virtual  aggregate 
simulates  creating  an  instance  for  each  data  value,  but 
actually  does  not  allocate  any  objects  in  memor  *.  It 
still  appears  to  the  test  of  the  code,  howeve  that 
there  is  an  objeo  for  each  value.  Using  these  tech¬ 
niques,  people  have  created  quite  large  applicaticms 
using  Garnet 


Fi^re  3: 

A  mesh  created  usiiig  a  viiuial  aggregate  for  the  polygons 
aivd  another  virtual  aggregate  for  the  square  knobs.  For  the 
polygons,  the  virtual  aggregate  is  passed  a  prototype  fen-  a 
polygon,  and  an  array  conuining  the  list  of  points  and  the 
color  for  each  polygon.  The  virtual  aggregate  then  pretends 
to  ailocaie  an  objea  for  each  element  of  the  array,  but 
actually  just  draws  the  prototype  object  repeatedly.  (Pic- 
une  courtesy  of  Kenneth  Meitsner  of  General  Electric 
[131.) 


5.  Constraints 

An  important  feature  of  Garnet  is  that  any  slot  of  any 
objea  can  contain  a  constraint  instead  of  a  normal 
value.  A  constraint  is  a  relationship  that  is  declared 
otKe  and  then  maintained  automatically  by  the  sys¬ 
tem.  For  example,  instead  of  making  one  endpoint  of 
a  line  be  (1Q.4S),  a  programmer  can  define  it  to  be  the 
same  as  the  center  of  the  left  edge  of  a  rectangle. 
Then  the  system  will  change  the  value  of  the  endpoint 
automatically  whenever  the  reaangle  moves.  The 
syntax  for  referencing  slots  of  objects  in  Garnet  is 


(gv  object  slot) ,  where  gv  stands  for  "gei- 
vaJue.” 

Although  many  other  research  systems  have  provided 
constraints.  Garnet  is  the  ftrst  to  truly  integrate  them 
with  the  object  system  and  to  make  them  general  pur¬ 
pose.  Cottsirairus  in  Garnet  can  be  any  Lisp  expres- 
sioa  An  imponaiu  result  of  these  design  decisions  is 
that  constraints  are  used  throughout  the  system  in 
many  different  ways.  For  example.  Garnet’s  im¬ 
plementation  of  a  Motif  radio  button  widget  uses  58 
constraints  internally,  and  the  Lapidary  graphical 
editor,  which  is  a  large  and  complex  application,  con¬ 
tains  16,7{X)  constraints.  Of  course,  many  of  these  are 
only  evaluated  once,  and  may  be  eliminated,  as  will 
be  discussed  later. 

Since  they  can  contain  arbitrary  code,  constraints 
mi^t  be  thought  to  be  like  methods,  and.  in  faa,  they 
serve  a  similar  purpose:  to  define  the  operation  of  ob¬ 
jects.  However,  the  importam  point  is  that  program¬ 
ming  with  constraints  is  a  different  style  than  pro¬ 
gramming  with  methods,  in  the  same  way  that  pro¬ 
gramming  with  methods  is  a  different  style  than  con¬ 
ventional  procedural  programming.  For  one  thing, 
constraints  are  automadcally  evaluated  when  neces¬ 
sary,  rather  than  requiring  the  programmer  to  invoke 
them  at  appropriate  times.  Secondly,  constraints  are 
declarative,  in  that  they  compute  the  values  of  vari¬ 
ables  (slots)  based  on  values  of  other  variables,  and 
do  not  have  side  effects.  Finally,  by  focusing  on  data 
values,  constraints  make  programming  more  data 
oriented,  rather  than  procedure  oriented.  Section  8 
discusses  why  constraints  provide  more  infonnaiion 
hiding  than  conventional  methods. 

One  obvious  use  of  constraims  is  to  tie  pans  of  com¬ 
posite  objects  together.  When  the  programmer  col¬ 
lects  together  a  set  of  objects  to  make  a  composite,  it 
is  necessary  to  specify  how  the  parts  relate.  Gamei 
provides  a  declarative  syntax  so  the  programmer  can 
simpiy  list  the  relationships  of  the  parts.  An  innova¬ 
tion  of  the  Garnet  constraint  system  is  that  the  objects 
can  be  referenced  through  pointer  variables  [251.  This 
is  used  to  allow  the  code  of  the  constraint  to  be  inde¬ 
pendent  of  the  specific  objects  used  for  the  pans.  In¬ 
stead,  the  constraint  will  reference  the  object  using  a 
"path"  through  the  aggregate  hierarchy.  For  ex¬ 
ample,  in  the  bunon  of  Figure  1.  the  bottom-edge 
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rectangle  can  refer  to  the  width  of  the  text  object 
using: 

Igv  :SVS  .'parcnc  ;wldcb) 

As  shown  in  Figure  4-a,  this  starts  from  the 
bottom-edge  rectangle,  goes  up  to  the  parent  ag¬ 
gregate,  down  to  the  label  part,  and  gets  the 
:  width  ftom  there.  Thus,  the  width  of  the 
bottom-edge  will  be  the  same  as  the  width  of  the 
label.  This  will  work  in  the  prototype,  as  well  as  in 
ail  instances,  since  Garnet  sets  pointers  to  the  ap¬ 
propriate  objects  into  the  slots  : parent,  .'fill- 
inside,  :  bottom-edge,  etc.  This  makes  it  easy 
for  Garnet  to  create  instances  of  the  entire  aggregate 
Cmduding  the  constraints),  since  Garnet  does  not  need 
to  edit  the  constrairit  code.  Because  this  style  of  con- 
straiiu  is  quite  common,  we  provide  an  abbreviation 
of  (gv  : SELF)  as  gvl.  Figure  4-b  shows  the  con¬ 
straints  used  to  tie  together  the  parts  of  the  button  of 
Figure  1. 

These  constraints  are  fairly  simple,  and  are  repre¬ 
sentative  of  the  majority  of  the  constraints  used  in 
Garnet.  However,  some  objects  have  quite  long  and 
complex  constraiius.  Fbr  example,  the  aggcegraph 
objea  is  a  special  type  of  aggregate  that  displays  its 
components  as  a  tree  or  graph,  and  it  has  a  very  large 
constraint  that  computes  the  graph  layout  information. 

Another  important  use  of  constraints  is  to  copy  values 
and  parameters  around.  For  example,  the  Motif  but¬ 
ton  prototype  takes  the  string  label,  the  color,  and  the 
position  as  parameters  (among  others).  These 
parameters  are  sup{^ied  as  values  in  the  slots  of  the 
top-level  widget  aggregate.  When  the  objea  is 
created,  the  programmer  can  specify  whichever  slots 
need  different  values  and  the  rest  are  inherited.  Of 
course,  any  value  can  be  changed  later  while  the 
widget  is  disj^ayed,  if  desired.  Note  that  this  is  quite 
differem  from  a  conventional  system  that  requires  the 
widget  creation  method  to  take  a  large  parameter  list 
with  all  possible  values  to  be  set,  and  therefore  re¬ 
quires  a  custom  creation  method  for  each  object.  In 
Garnet,  the  standard  create-instance  routine  is 
used  for  all  objects,  and  it  can  be  used  to  set  an  ar¬ 
bitrary  number  of  slots. 

Although  the  slots  which  serve  as  parameters  are  in 
the  top-level  button  aggregate,  for  these  values  to  ac¬ 
tually  take  effect  they  must  be  copied  down  to  the 


(a) 


(er*4C*-lnscanc*  'buccon 
t:l€ft  20)  ;  Thtuarttht 

(:top  20)  ;  paramtunU 

(sxexlnq  'labal'*)  ;  Utt  biutan. 

(: paxes 

( ( : cop-*dga  xsctsngla 

(foxmuls  (gvl  :pax*nt  :Iafe))) 

(:cop  (lexnuls  (gvl  :psx*nc  :eop))) 

(:uidch  (foxmuls 

(4'  (gvl  :psx*nc  :lsl9«l  :widch)  S))) 
(:b*lghc  (foxmuls 

I*  (gvl  :psxonc  :ls)3«l  :)i«ighc)  8)1) 
ceolox  whico) ) 

(:]>octoiii-«dg«  xoecsnglo 

(slofe  (foxnuls  (*  2  (gvl  jpsxcnc  :l«fc)))) 
(:cop  (foxmuls  (+  2  (gvl  :psronc  :cop)))) 
(swldeh  (foxmuls 

(*  (  (gvl  spsxonc  :lsb«l  swldeh)))) 
(:h«ighe  (foxnuls 

<*  6  (gvi  spsroflC  :lsb«l  ihoight)))) 
(:eolox  blsek)) 

(:fill-insid«  roecsnglo 
{:l«fc  rfoxmuls 

(gvl  ipsxone  :boccom-«dgo  :lofc>)) 

(:cop  (foxmuls 

(gvl  :psr«ne  :boccon~«dg«  :eop))) 

(:uldeh  (foxmuls 

(-  (gvl  :pBXOne  :boetem-«dg«  :widch)  2))) 
(:h«ight  (foxnuls 

(-  (gvl  rpsronc  :bocxom-odgs  :h«ighe)  2))) 
(:colox  grsy) ) 

(:lsb«l  eoxt 

(:lsft  (foxmuls 

,  (concox-x  (gvl  :psxonC  : fill-inside) I ) ) 
(:eop  (foxmuls 

(cencex-/  (gvl  ipsrenc  ; fill-inside) I ) ' 
(:sciing  (foxnuls  (gvl  :psxen£  :scring) ) ) > ) ) ) 

(b) 

Figure  4: 

(a)  The  structure  of  the  objects  in  the  button  of  Figure  I 
showing  the  references,  (b)  The  complete  ccxte  used  to 
produce  the  button.  This  shows  the  consuaints  which  put 
the  graphics  in  the  correct  places  and  copy  the  parameter 
values  to  the  pans. 


appropriate  (daces  in  the  components.  For  example, 
the  string  value  is  specified  at  the  top  level  in  Figures 
1  and  4-b,  but  it  is  needed  by  the  text  object  So  there 
is  a  constraint  in  the  text  object  that  copies  the  value 
of  the  parameter.  Of  course,  since  constraints  can  be 
arbitrary  Lisp  code,  the  values  can  be  transformed  ar¬ 
bitrarily  as  needed.  Since  constraints  are  used  to 
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propagate  the  values,  the  objects  do  not  have  to  do 
anything  special  to  allow  changes  at  nm-cime;  if  one 
of  the  parameter  slots  is  changed,  the  constraints 
automatically  propagate  the  change  a{:^ropriately,  and 
the  update  algorithm  will  make  sure  the  object  is  then 
redrawn. 

An  interesting  observation  about  this  use  of  con¬ 
straints  is  ths  it  allows  arbUreoy  delegation  of  values, 
not  just  fh>m  prototypes.  Any  slot  can  ^  its  value 
£n»n  any  slot  of  any  other  object  through  constraints. 
Therefore,  the  constraints  can  be  used  as  a  form  of 
inheritance.  Of  course,  constraints  are  more  powerful 
than  amvendonal  inheritance  since  they  can  perform 
artnoaiy  transformations  on  the  values. 

As  with  the  graphical  objects  themselves,  constraints 
can  be  defined  interactively  using  varioas  editors. 
Lapidary  provittes  some  iconic  menus  for  defining  the 
most  popular  constraints  (Figure  S).  We  have  found 
that  these  are  sufficiem  for  most  graphical  applica¬ 
tions.  For  more  complex  constraints,  a  spreadslreet- 
Iflce  interface,  udiich  is  called  C32,  provides  a  number 
of  features  to  help  programmeis  who  do  not  know  the 
exact  syntax  [19].  Fbr  example,  C32  has  menus  thtit 
will  insert  commonly  used  functions.  Also,  the  ust.' 
can  point  to  objects  with  the  mouse  and  C32  will  in¬ 
sert  a  reference  into  the  constraint  using  the  correa 
path  expression.  Of  course,  it  also  balances  paren¬ 
theses.  In  the  foture,  we  will  explore  automatic  in- 
ferendng  of  constraints,  as  was  done  in  Peridot  [14], 
We  envision  that  when  “guessing"  mode  is  turned 
on,  the  system  will  try  to  find  a  likely  constraint  be¬ 
tween  the  newly  drawn  object  and  the  neighboring 
objects. 


Box  Consiraini  Menu 


Limt  CamsXraimI  Mtm» 


«Q] 


The  performance  of  constraints  in  Garnet  is  quite  fast. 
Evaluating  constraints  is  not  much  slower  than  the 
calculations  the  programmer  would  have  to  perform 
anyway.  On  a  Sun  SPARCstaiion  1,  a  simple  con¬ 
straint  evaluation  (in  Lisp)  takes  1 10  microseconds. 
This  means  that  objects  tracking  the  mouse  can  afford 
to  have  dozens  of  constraints  being  re-evaluated  for 
each  incremental  mouse  movement.  The  system 
caches  old  values  for  constraints,  so  ones  that  do  not 
change  value  are  not  re-evaluated.  We  have  dis¬ 
covered  that  the  primary  performance  problem  with 
constraints  is  not  speed,  but  rather  space.  For  each 
constrairu  there  must  be  pointers  from  slots  that  are 


Figure  S: 

The  dialog  boxes  from  Lapidary  [15]  that  allow  the  most 
common  consoainis  to  be  set  The  menu  on  the  top  is  for 
rectangular  objects  (which  includes  circles  and  aggregates), 
and  the  one  on  the  bottom  is  for  attaching  lines  to  each 
other  or  u>  rectangular  objects.  For  the  box  constraints,  the 
column  of  buttons  label^  :top  will  cause  the  dependent 
object  to  be:  on  top  of  the  other  object,  just  inside  the  other 
object,  centered  vertically  in  the  object,  just  above  the  other 
object,  or  just  below  the  other  object.  Similarly,  the  row  of 
buttons  labeled  :left  determine  the  horizontal  relationship. 
The  butmn  on  the  bottom  constrains  the  width,  and  the  one 
on  the  light  constrains  the  height.  The  text  fields,  like 
offset  and  scale  are  used  to  supply  parameters  to  the 
constraints.  For  lines,  either  end  of  the  line  can  be  attached 
tti  various  positions  of  a  box-like  c^ject  or  of  another  tine. 
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referenced  to  the  constraints  that  use  them,  and  from 
constraints  to  the  slots  they  reference.  We  observed 
that  many  of  the  constraints  are  only  used  once  when 
the  objea  is  initially  placed,  so  we  devised  a  tech¬ 
nique  where  no  memory  is  allocated  for  these  con- 
oraints.  Hiis  has  been  enormously  effective,  and 
decreases  the  total  run-time  storage  requirements  of 
applications  on  average  by  about  S0%.  For  some 
dialog  boxes,  like  the  color  selection  palette,  1500 
constraints  are  reduced  to  only  100.  As  an  example 
of  a  large  scale  application,  6690  constraints  (which  is 
over  40%)  are  eliminated  from  the  Lapidary  graphical 
editor. 

The  use  of  constraints  provides  the  programmer  with 
a  number  of  important  benefits.  The  most  obvious  is 
that  the  system  maintains  the  relationships  among  ob¬ 
jects  that  otherwise  would  be  the  responsibility  of  the 
programmer.  More  relevaru  to  this  paper,  however,  is 
that  constraints  allow  objects  to  provide  an  abstract 
interface  through  top-level  variables,  and  the 
programmer  can  declaratively  specify  how  to  trans¬ 
form  the  values  for  all  components.  In  fact,  if  you 
need  to  use  methods,  constraints  can  even  be  used  to 
dynamically  determine  which  method  to  use  for  a 
message  based  on  the  current  state.  This  works  be¬ 
cause  the  value  of  any  slot  can  be  computed  using  a 
constraint,  and  the  value  returned  can  be  a  function. 
However,  we  do  not  Imow  of  anyone  using  this  fea¬ 
ture. 

6.  Input  Model 

Virtually  all  toolkits,  graphics  packages,  and  window 
managers  use  the  same  input  model:  a  stream  of  input 
event  records  is  sent  to  the  appropriate  window.  The 
application  program  is  expected  to  de-queue  these 
events  and  interpret  them.  Garnet  uses  an  entirely  dif¬ 
ferent  model,  based  on  encapsulating  input  behaviors 
separately  from  the  graphics  (16, 18].  This  handles 
all  input  so  objects  never  need  event-handling 
methods. 

Garnet  provides  seven  basic  "Interactor”  objects  that 
handle  all  of  the  most  common  direct  manipulation 
behaviors.  The  Interactor  objects  in  Garnet  are  com¬ 
pletely  independent  of  any  graphical  representation. 


and  are  purely  input  filters.^  The  seven  types  of  Inter- 
actors  currently  in  Garnet  are: 

Menu-Interactor  -  Used  to  select  one  or  more 
from  a  set  of  objects.  This  can  be  used  for  menus, 
radio  bunons,  check  boxes,  simple  push  buttons, 
and  the  arrows  on  scroU  bars.  In  addition,  this 
can  be  used  to  cause  application  objects  to  be¬ 
come  selected  in  a  graphics  editor. 

Move-Grow-Interactor  -  This  is  used  to  move 
an  object  or  one  of  a  set  of  objects  using  the 
mouse.  There  may  be  feedback  to  show  where 
the  object  will  be  moved,  or  the  object  itself  may 
move  with  the  mouse.  This  Interactor  can  be  used 
to  implement  the  indicator  for  one-dimensional  or 
two-dimensional  scroll  bars,  and  also  for  moving 
application  objects  in  a  graphics  editor. 

New-Point-Interactor  -  This  is  used  when 
one,  two  or  an  arbitrary  number  of  new  points  are 
desired  from  the  mouse. 

Angle-Intsractor  -  This  is  used  to  get  the  angle 
the  mouse  moves  around  some  point  It  can  be 
used  for  circular  gauges  or  for  rotating  objects. 

Trace-Interactor  -  This  is  used  to  get  all  of  the 
points  the  mouse  goes  through  between  start  and 
end  events,  for  use  in  free-hand  drawing. 

Text-String-Interactor  -  This  is  used  to  edit 
text  and  supports  single-line,  or  multi-line  and 
multi-font  strings.  A  key  translation  table  allows 
arbitrary  mappings  of  editing  operations. 

Gesture-Interactor  -  This  supports  freehand 
gesturing,  like  drawing  an  "X"  on  top  of  an  object 
to  delete  it. 

Unlike  other  implementations  of  the  Model-View- 
Controller  idea,  in  Garnet  the  programmer  never 
needs  to  create  new  kinds  of  “controllers.”  It  is  only 
necessary  to  create  an  instance  of  a  pre-defined  Inter¬ 
actor  and  to  supply  a  few  parameters.  An  important 
reason  that  this  works  is  that  we  have  carefully 
chosen  the  parameters  so  that  they  suppon  the  fuU 
range  of  direct  manipulation  iriterfaces.  For  example, 
the  designer  can  specify  which  mouse  button  or 
keyboard  key  causes  the  Interactor  to  start  operating, 
and  which  causes  it  to  stop.  Menu-interactors  can  be 
told  whether  single  or  multiple  selections  are  desired. 
The  most  important  parameters,  however,  are  the 


^Noie  thu  this  use  of  the  term  "InieTicior"  is  differew  from 
some  other  systems  that  use  the  term  for  an  entire  widget 
(graphics  plus  behaviors).  In  Camel.  Iniera.:iors  have  no 
gr^thics.  only  behavior. 
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graphics  that  the  Inieraciors  operate  over.  We  have 
obsen^ed  that  although  direct  manipulation  interfaces 
vary  widely  in  their  “look.”  they  are  mostly  identical 
in  their  "feel’*  or  behavior.  Therefore,  by  separating 
the  behavior  from  the  graphics,  and  including 
parameters  for  the  most  pojxilar  options,  virtually  all 
behaviors  can  be  provided  without  requiring  new 
code. 

For  examine,  to  create  an  intenaor  which  moves 
around  any  of  the  objects  which  ate  components  of  an 
aggregate  called  my-agg,  the  following  is  all  that  is 
needed: 

(cra«c*-inatanc*  'ny-mov«r  Hova-Crow-Inccractor 
(: f««db4ck-ob3  ny-r«*db«ck-r*ct I 
(.-sc*re-wh«ra  '  ( :*l«iMnt-er  ny-4qq)ll 

The  rest  of  the  properties  of  my-mover  will  use  the 
default  values  (start  on  left  button  down,  move  the 
objea  rather  man  grow  it.  etc.).  After  it  is  created, 
my -moves  will  continuously  watch  for  a  mouse 
leftbution  press  over  any  of  the  objects  in  my-agg. 
When  this  happens,  it  will  make  the  feedback  object 
(my-feedback-rect)  visible  and  begin  moving  it 
to  follow  the  mouse  until  the  mouse  button  is 
released.  At  that  point,  the  my-feedback-rect 
will  become  invisible  and  the  actual  object  will  be 
moved.  Gf  no  feedback  object  had  been  supplied, 
then  the  element  of  my-agg  would  be  directly 
dragged  by  the  mouse.) 

There  is  a  standard  protocol  through  which  the  Inter- 
actors  interface  to  the  graphical  objects.  The 
move-grow-interactor  sets  the  :box  slot  of 
objects,  and  the  :  left  and  ;  top  slots  would  be  tied 
CO  the  ;box  slot  with  constraints.  This  allows  theie 
to  be  arbitrary  filtering  without  the  Inieractor  having 
to  know  about  it.  To  find  which  object  is  under  the 
mouse,  the  Interactor  sends  a  message  to  the  ag¬ 
gregate.  This  will,  in  turn,  send  messages  to  each  of 
the  components.  However,  the  programmer  never  has 
to  write  methods  for  these,  since  all  graphical  objects 
are  created  by  combining  the  Garnet  primitives  which 
supply  the  appropriate  methods. 

The  Menu-Interactor  has  two  piutocols;  it  can 
take  a  separate  feedback  object  as  a  parameter,  or  it 
will  directly  modify  the  object  that  becomes  selected. 
If  there  is  a  feedback  object,  then  its  :ob 3-over 
slot  is  set  to  the  object  that  becomes  selected.  The 
feedbacjt  object  is  expected  to  have  constrainu  that 


will  cause  tlic  position  and  size  to  depend  on 
whatever  object  is  set  into  the  :  ob  j-over  sIol  For 
example,  the  left  formula  might  be  (gvl  -.obj- 
over  :  left ) .  which  will  make  the  feedback  object 
have  the  same  left  position  as  whatever  object  is 
selected.  Notice  that  the  Interactor  does  not  need  to 
know  whether  the  feedback  object  is  a  simple  XOR 
rectangle  or  an  aggregate  containing  squares  that 
serve  as  seleaion  handles. 

If  there  is  no  feedback  object,  then  the 
menu-interactor  sets  the  : selected  slot  of 
the  object  itself.  There  might  be  constraints  that 
change  position,  color  or  font  based  on  whether  the 
object  is  selected  or  not.  For  example,  to  implement  a 
Motif-like  pushed-in  appearance  for  the  bunon  of 
Figure  6.  the  color  of  the  :  top-edge  might  be  com¬ 
puted  by  the  constraint: 

(if  (qvl  iparanc  ;s«l«cc«cti 
bltck  ;  (kMcost 
whit«l  ;  *luciu* 

The  formula  on  the  ; bottom-edge  would  be  the 
opposite,  and  the  color  of  the  fill- inside  would 
choose  between  gray  and  dark-gray.  Note  that  this  is 
all  perfonned  without  methods:  the  parameters  to  the 
Interaciors  are  values  in  slots,  and  the  interface  be¬ 
tween  the  Interactors  and  the  graphical  objects  is 
through  seeing  well-defined  slots  in  the  graphics. 

It  is  always  legal  in  Garnet  to  set  a  slot's  value  (the 
slot  docs  not  have  to  be  pre-defined).  Therefore,  if 
the  programmer  does  not  want  anything  to  happen 
when  the  object  becomes  selected,  he  or  she  can 
simply  not  anach  any  constraints  to  the  slots.  There  is 
never  a  worry  of  a  "Message-not-undcrslCKXl'’  *rror 
as  in  a  conventional  class-instance  system,  where  the 
programmer  would  have  to  define  an  appropriate 
method  at  the  root  class  (c.g.,  ob  ject).  to  make  sure 
that  there  would  never  be  a  run-time  error  if  arbitrary 
objects  could  be  selected. 

Since  Interaciors  can  be  specified  by  filling  in 
parameters,  it  is  easy  to  create  them  in  interactive 
editors.  For  example.  Lapidary  provides  a  dialog  box 
for  each  tmeracior  type  that  allows  graphics  to  be  at¬ 
tached  and  parameters  to  be  set.  This  is  how 
Lapidary  allows  arbitrary  behaviors  to  be  connected 
to  application-specific  graphics  interaaively,  without 
requiring  the  programmer  to  write  code.  Interaciors 
can  be  added  to  aggregates,  so  the  single 
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Figure  6: 

Hie  button  of  Figure  1  can  be  made  to  look  like  it  moves  in 
3-p  by  changing  the  coltvs  of  the  pans.  The  Interactor 
dees  not  need  to  know  bow  the  button  responds  to  becom¬ 
ing  selected. 


creace-instance  call  will  create  t^e  graphics 
and  Interactors  necessary  for  an  object  to  behave  cor¬ 
rectly. 

Wc  have  found  the  Interactor  model  to  be  extremely 
effective.  This  model  makes  it  much  easier  to 
program  direa  manipulation  interfaces.  However,  we 
have  found  a  few  cases  where  the  built-in  parameters 
are  not  sufHdem.  In  this  case,  it  is  possible  for  the 
programmer  to  write  methods  to  filter  the  data.  Typi¬ 
cally,  these  are  used  when  custom  processing  is 
needed  when  the  Interacttir  starts,  stops  or  aborts. 
Even  when  this  is  required,  however,  the  interface  the 
programmer  sees  is  still  higher-level  than  conven¬ 
tional  event-handling.  Details  are  available  elsewhere 
120]. 

7.  Example  and  Comparisons 
To  give  an  example  of  the  style  of  programming  in 
Garnet,  we  will  sketch  the  implementation  of  the  toy 
graphics  editor  in  Figure  7  and  compare  it  with  the 
implementation  in  conventional  object-oriented  lan¬ 
guages.  Here,  every  time  the  user  clicks  with  the 
right  mouse  button  in  the  drawing  window,  a  new  box 
and  arrow  is  created  using  the  current  line  style 
(which  is  shown  on  the  left).  The  arrows  always  go  to 
the  previously-created  box.  The  user  can  click  with 
the  left  mouse  button  to  select  objects,  and  the 
handles  appear.  Dragging  a  handle  moves  or  grows 
the  selected  object  The  Delete  bunon  deletes  the 
selected  object,  and  pressing  on  a  new  line  style  while 
an  object  is  selected  causes  the  object  to  change.  Of 
course,  much  of  this  program  could  be  created  using 
the  Lapidary  graphical  editor  without  writing  any 
code,  but  we  will  assume  here  that  Lapidary  is  not 
being  used,  and  the  programmer  wants  to  write  every¬ 
thing  by  hand. 


E3 
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Figure  7: 

A  simple  editor.  Box  3  has  been  selected  by  the  user,  and 
tlie  current  line-style  (shown  on  the  left)  is  a  thin  line. 


To  implement  this  in  Garnet,  the  programmer  would 
first  create  prototypes  for  the  two  kinds  of  objects  that 
can  be  created;  an  arrow,  and  an  aggregate  conuining 
a  rounded-rectangle  and  a  text  objea.  The  aggregate 
will  conuin  constraints  that  keep  the  text  centered  at 
the  tt^  of  the  rounded  rectangle.  Then,  a  main  win¬ 
dow  would  be  created  containing  the  buttons  for 
delete  and  quit,  and  four  line  objects  to  serve  as  a 
palette.  A  rectangle  would  be  added  to  show  which 
line  style  is  selected,  and  a  menu-interactor  would  be 
atuched  to  the  four  lines  with  the  recungle  as  the 
feedback. 

To  allow  new  objects  to  be  created,  a  New-Point- 
Interactor  would  be  added  to  the  right  part  of  the 
window  which  starts  on  the  right  button.  A  parameter 
to  this  interactor  is  the  prototype  from  which  in¬ 
stances  will  be  created.  Here,  this  slot  will  contain  an 
aggregate  conuining  the  prototype  box  and  arrows. 
Formulas  in  the  prototypes  will  cause  the  arrows  to 
have  the  appropriate  end  points  and  'he  string  to  have 
the  appropriate  value. 

To  make  the  objects  seleaable.  it  is  only  necessary  to 
include  the  pre-defined  selection-handle- 
widget.  which  displays  the  squares  around  the  ob¬ 
jects  and  allows  objects  to  be  resized  and  moved.  In¬ 
ternally,  this  widget  contains  many  formulas  that 
cause  the  squares  to  be  attached  to  the  objects  at  the 
appropriate  places  (it  works  for  both  boxes  and  lines). 
The  value  of  the  selection-handle  widget  is  the 
selected  object,  which  will  be  accessed  by  the  call¬ 
back  functions  for  changing  the  line-style  and  delete. 
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To  compare  the  implementations,  we  asked  a  number 
of  people  to  implement  the  same  editor  in  different 
objea  systems  and  toolkits.  Most  of  these  people 
wens  the  designers  of  the  toolkits. 

One  implementation  was  in  GINA-m-,  a  research 
toolkit  in  C-h>  from  the  German  National  Research 
Center  for  Computer  Science.^  The  implementation 
defines  classes  for  the  line-style  palette  items,  for  the 
commands  for  creating  and  deleting  objects,  for  the 
graphical  objects,  and  for  the  editor  and  its  panes. 
Methods  on  the  graphical  objects  include  setting  and 
accessing  the  "to”  and  "from"  objects  (for  the  ar¬ 
rows).  drawing,  and  drawing  with  dashed  outline  to 
serve  as  a  feedback  object  Methods  for  the  editor 
include  creating  the  windows,  and  accessing  and  set¬ 
ting  the  current  line-style  and  the  selected  object 
GINA-h-  provides  a  retained-objea  model,  so  the 
I»Dgiammer  does  not  need  to  write  erase  or  redisplay 
methods.  Sup^rt  for  selection  handles  around  a  rec¬ 
tangular  object  is  built  in.  but  the  programmer  over¬ 
rode  the  selection  draw-method  for  lines  to  only  show 
handles  at  the  end  points.  To  handle  creating  new 
objects,  when  GINA-t-*-  sends  the  bucton_press 
message  to  the  background  window,  the  Great  «Box 
object  is  created.  This  special  command  objea 
defines  mediods  to  handle  the  incremental  feedback 
when  dragging  out  a  new  box,  and  then  creating  a 
new  rounded-rectangle  and  a  new  arrow  when  the 
mouse  buttmi  is  released. 

CLIM  [11]  is  a  popular  commercial  Lisp  toolkit  that 
uses  CLOS,  the  standard  Common  Lisp  object  sys¬ 
tem.  Like  Garnet,  CLIM  supplies  a  retained  object 
moctel  with  incremental  redisplay  (which  they  call 
"streams”)  and  high-level  input  handling  (called 
"translators").  Also,  CLIM  provides  a  declarative 
mechanism  for  defining  the  window  layout,  but  not 
for  objea  definitions,  so  the  programmer  wrote  draw- 
methods  for  the  objects  and  selection  handles.  The 
programmer  also  had  to  write  an  event  handler  for  the 
creation  of  objects,  since  there  is  not  an  appropriate 
"translator.” 

In  both  GINA+-*-  and  CLIM,  methods  are  needed  for 


*For  mote  infoonuion  on  GINA-t^  or  CLM/GINA  for  Lisp, 
contact  Mike  Spenke,  P.O.  Box  1316,  D-W-SIOS  Sl  Augusan  1. 
Gennany,  -t49  2241  14-2642.  spenke@gmd.de. 


drawing  objects,  since  they  carmot  be  specified 
declaiativcly.  How  the  rectangle  the  text  is  displayed 
is  hard-wired  into  the  draw  method  of  the  box  class, 
and  thus  it  might  be  harder  to  modify  than  in  GameL 
especially  by  interactive  programs.  Because  d^y  do 
not  have  constraints,  (he  cooe  must  explicitly  redraw 
the  lines  and  the  text  label  when  the  box  is  moved, 
whereas  in  Garnet  this  is  handled  automatically. 

As  a  small  measure  of  whether  the  Garnet  technique 
is  mote  effective.  Figure  8  shows  the  coding  time  and 
size  information  for  seven  implementations  of  the 
editor  in  Figure  7.  All  but  the  MacApp  one  was  im¬ 
plemented  by  ore  of  the  designers  of  the  toolklL  so 
you  can  expea  that  they  knew  the  systems  well  The 
MacApp  implementor  was  also  an  expen  with  his  sys¬ 
tem.  Zdrava  is  an  experimental,  unfinished  system, 
so  the  times  for  it  are  simply  estimates  from  the  desig¬ 
ner.  Of  course,  these  numbers  do  not  constitute  a 
scientific  study,  and  the  other  programmers  did  not 
know  that  they  were  participating  in  a  time  tesL  Fur¬ 
thermore,  the  example  was  chosen  by  the  Garnet 
designer.  Still,  the  dau  does  suggest  that  graphical 
programs  can  be  smaller  and  written  faster  in  Garnet 


System 

Time 

Lines  of  Code 

Ganei 

BSSS!lES!3 

2J  hrs 

183  lines 

CUM-tZikav* 

Common  Lisp 

Z5  hn  (esc) 

190  (cst.) 

CUM 

Common  Lisp 

4  J  hrs 

331  lines 

Objea  Pascal 

9  his 

1026  lines 

GINA-m- 

C-M- 

16  hours 

SSO  lines 

Common  Lisp 

2  days 

BSSISSHli 

CLM.  GINA 

Common  Lisp 

2  lo  3  days 

273  Unes 

Figure  8: 

Times  and  code  size  to  create  the  editor  of  Figure  7  using 
various  systems.  CLIM  and  GINA  are  discussed  in  the 
article.  MacApp  is  a  commercial  product  of  Apple  and 
LispView  is  a  commercial  product  of  Sun. 


3.  Modularity 

Some  people  claim  that  using  methods  is  a  better  in¬ 
terface  to  objects  because  it  supports  better  infor¬ 
mation  hiding.  The  motivation  is  that  the  internal  im¬ 
plementation  of  the  object  can  be  mote  easily  changed 
if  ihc  interface  is  through  methods.  Therefore  some 
object  systems,  such  as  SELF  [5],  do  not  allow  direct 
access  to  any  objea  variables,  but  only  provide  access 
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thiough  methods.  Garmst  takes  an  opposite  approach, 
and  the  main  interface  is  through  the  data  of  objects. 
However,  this  can  be  just  as  modular. 

8.1  Data  vs.  Methods 

In  Gamet,  an  object  advertises  its  input  and  output 
slots,  and  most  objects  of  the  same  type  use  the  same 
slots  (for  example,  all  graphical  objects  have  :  lef  c  / 
:top,  rwidth,  rheight,  rfilling- 
style,  etc.).  This  corresponds  to  advertising  the 
»poTted  methods  in  other  objea  systems.  In  Gamet, 
through  the  use  of  constraint  formulas,  objects  can 
transform  the  parameter  values  in  whatever  way  is 
desired.  For  example,  the  Manu- Interact  or  sets 
the  :  selected  slot  of  objects.  It  is  up  to  the  inter¬ 
nal  oonstraiius  in  the  selected  object  what  this  does,  if 
anything.  The  color,  position,  or  fora  of  the  object 
mi^  have  a  formula  depending  on  the  :  selected 
slot,  and  the  Interactor  does  not  care.  This  interface  is 
just  as  modular  as  if  the  Interactor  called  a  generic 
Become-Selected  method. 

Although  Gamet  does  not  currently  provide 
mechanisms  to  declare  which  dots  of  an  object  can  be 
used  fiom  outside  and  which  are  internal,  this  could 
easily  be  added.  This  would  provide  the  same  protec- 
tkm  as  class-instance  models  which  have  public  and 
private  mefoods. 

8.2  Constraints  vs.  Methods 

Constraints  also  contribute  to  modularity  in  another 
way,  by  fixing  a  flaw  in  the  conventional,  imperative 
objea-oriented  model.  In  the  conventional  model,  to 
achieve  certain  types  of  behavior,  the  programmer 
must  either  explicitly  arrange  the  methods  so  they  ex¬ 
ecute  in  the  proper  order,  thus  violadng  the 
modularity  of  objects,  or  else  allow  the  methods  to 
execute  in  an  arbitrary  order,  thus  evaluating  methods 
more  times  than  necessary,  and  possibly  destroying 
the  correctness  of  the  program  if  the  methods  commit 
side-effects.  For  example,  suppose  that  a  programmer 
wants  to  keep  a  box  called  A  centered  above  two  other 
boxes  called  B  and  C  (Figure  9).  In  a  conventional 
system,  the  programmer  might  add  a  message  to  the 
move  methods  in  B  and  C  that  calls  a  centering 
method  in  A.  Later  the  programmer  decides  that  C 
should  always  be  20  pixels  to  the  right  of  B.  The 
programmer  thus  expands  the  move  method  in  B  to 
send  a  message  to  the  move  method  in  C.  Without 


proper  sequencing,  the  centering  method  in  A  may  be 
called  twice,  once  by  the  move  method  in  A,  and  once 
by  the  move  method  in  B.  However,  the  centering 
method  in  A  should  only  be  called  once,  after  the 
methods  in  both  B  and  C  have  terminated. 


Figure  9: 

A  box  ceniend  over  two  other  boxes.  If  either  box  B  or  c 
moves,  box  A  should  move  so  that  it  stays  centered  over  the 
boxes. 


In  this  case,  the  programmer  is  faced  with  two  equally 
unpalauble  choices.  The  programmer  can  choose  not 
to  provide  explicit  sequencing,  in  which  case  the 
centering  method  in  A  may  execute  twice.  This  is  both 
wasteful  and  potentially  dangerous  if  the  centering 
method  commits  side-effects  (in  this  case  it  probably 
would  not,  but  obviously  there  are  situations  where 
this  could  pose  a  problem).  Alternatively,  the 
programmer  could  rely  on  the  fact  that  the  move 
method  in  C  calls  the  centering  method  in  A,  and  thus 
not  call  the  ceraering  method  itself.  However,  the  im- 
plementadon  of  the  move  method  in  B  now  depend  on 
the  implementation  of  foe  move  method  in  C,  which 
violates  the  notion  of  modularity. 

Notice  that  in  cither  case  the  modularity  principle  is 
additionally  violated  because  B  and  C  have  to  know 
that  A  depends  on  them  (and  later  B  has  to  know  that 
C  depends  on  it).  If  the  centering  relationship  be¬ 
tween  A,  B,  and  C  is  later  destroyed,  not  only  must  the 
centering  method  in  A  be  deleted,  but  the  move 
methods  in  B  and  c  must  be  changed  as  well.  (A 
similar  siniation  arose  in  the  example  of  Figure  7. 
where  the  convendonai  systems  put  code  in  the 
methods  of  the  boxes  to  maintain  the  lines.) 
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In  a  constraint-driven  language,  neither  of  these 
problems  arises  since  the  constraint  solver  handles 
both  communication  between  objects  and  the  ordering 
of  constraints.  In  the  ^ve  example,  the  programmer 
would  initially  write  a  constraint  that  centered  A 
above  B  and  C.  Later  the  programmer  would  add  an 
additional  constraint  placing  C  20  pixels  to  the  right 
of  B.  The  constraint  solver  would  automatically  en¬ 
sure  that  the  constraints  were  evaluated  in  the  proper 
order.  Thus  the  programmer  would  not  have  to  worry 
about  sequencing.  In  addition,  the  move  methods  for 
B  and  C  would  not  have  to  Icnow  about  the  relation¬ 
ships  among  the  three  objects  (the  constraint  solver 
would  be  responsible  for  propagating  the  change  in¬ 
formation),  so  they  would  simply  modify  the  local 
state  of  their  objea.  If  one  or  both  of  the  constraints 
were  later  deleted,  the  move  methods  would  not  have 
to  be  modified.  Titus  constraint-driven  programming 
better  preserves  the  modularity  of  objects. 

8.3  Interactors  vs.  Methods 

The  Garnet  input  model  also  provide  better 
modularity  than  found  in  other  systems.  The  graphics 
are  entirely  independent  of  the  behaviors,  and  they 
can  be  developed  and  modified  separately.  In  other 
systems,  models,  views  and  controllers  have  always 
been  tightly  coupled,  so  they  all  had  to  be  carefully 
modified  together. 

8.4  Re-use 

Another  key  feature  of  Garnet  is  that  it  provides  better 
software  re-use  than  most  other  toolkits.  The 
programmer  does  not  have  to  re-program  new  event 
handlers,  since  the  built-in  Interactors  are  sufficient. 
The  programmer  does  not  need  to  deal  with  window 
refresh  or  maintaining  relationships  among  objects, 
since  the  object  system  and  constraint  solver  handle 
this.  In  addition,  since  we  can  be  sure  that  there  is  an 
objea  in  memory  for  every  object  on  the  screen,  it  is 
possible  to  provide  higher-level  widgets,  such  as  the 
selection-handles.  The  handles  contain  constraints 
that  reference  the  selected  object.  Toolkits  without 
retained  objeeu  eannot  supply  selection  handle 
widgets  because  they  would  need  to  access  the 
application’s  internal  data  structure  to  know  where 
objects  are  and  how  to  move  and  grow  the  objects. 

Another  feature  of  Garnet  is  that,  if  the  programmer 
wants  to  make  a  slight  modification  of  an  existing  ob¬ 


ject.  it  is  only  necessary  to  specify  the  specific 
changes  to  the  graphics,  rather  than  having  to  write 
completely  new  draw  methods. 

9.  Conclusion 

The  style  of  programming  in  the  Garnet  objea  system 
is  quite  different  from  other  objea  systems;  'he 
programmer  collects  together  graphical  objects,  writes 
constraints  to  define  the  relationships  among  them, 
and  then  attaches  instances  of  pre-defined  interactor 
objects  to  cause  the  objects  to  respond  to  the  user. 
Usually,  much  of  the  “programming”  can  be  done 
with  graphical,  interactive  tools,  rather  than  by  writ¬ 
ing  code.  Even  when  not  usit.g  interactive  tools, 
programmers  rarely  write  methods  when  creating 
Garnet  code.  Our  experience  suggests  that  this  style 
of  programming  is  much  more  effective  for  graphical 
user  interfaces.  It  would  be  interesting  to  see  which 
other  types  of  programming  it  works  well  for.  For 
example,  object-oriented  data  bases  seem  like  a  good 
candidate,  since  they  clearly  use  a  “retained-objea 
model.”  and  a  primary  use  of  methods  there  is  to  up¬ 
date  objects  and  to  maintain  consistency  among 
various  objects.  Many  other  application  areas  might 
also  benefit  from  this  style  of  programming. 
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The  Garnet  toolkit  was  specincally  de¬ 
signed  to  make  highly  interactive  graphi¬ 
cal  programs  easier  to  design  and  imple¬ 
ment.  Visual,  interactive,  user-interface  de¬ 
sign  tools  clearly  fall  into  this  category. 
At  this  point,  we  have  used  the  Garnet 
toolkit  to  create  three  difleient  interactive 
design  tools:  Gilt,  a  simple  interface  build¬ 
er  for  laying  out  widgets;  Lapidary,  a 
sophisticated  design  tool  for  constructing 
application-specific  graphics  and  custom 
widgets;  and  C32,  a  spreadsheet  interface 
to  constraints.  The  features  of  the  Garnet 
toolkit  that  made  these  easier  to  create  in¬ 
clude  use  of  a  prototype-instance  object 
system  instead  of  the  usual  class-instance 
model,  integration  of  constraints  with  the 
object  system,  graphics  model  that  sup¬ 
ports  autoinalic  grapliical  ii(Htalc  and  sav¬ 
ing  to  disk  of  on-screen  objects,  separation 
of  specifying  the  graphics  of  objects  from 
their  behavior,  automatic  layout  of  graphi¬ 
cal  objects  in  a  variety  of  styles,  and  a  wid¬ 
get  set  that  supports  such  commonly  used 
operations  as  selection,  moving  and  grow¬ 
ing  objects,  and  displaying  and  setting 
their  properties. 

Key  words:  User-interface  design  environ¬ 
ments  -  Toolkits  -  Object-oriented  sys¬ 
tems  -  Constraints  -  Input  handling  - 
Garnet 
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1  Introduction 

Creating  visual  interactive  design  tools  can  be  a 
difficult  task  when  the  appropriate  support  is  not 
available.  The  Garnet  toolkit  (Myers  et  al.  1990) 
was  specifically  designed  to  make  the  construction 
of  interactive,  graphical,  direct  manipulation  pro¬ 
grams,  including  interactive  user-interface  builders, 
significantiy  easier.  A  toolkit  is  a  collection  of  inter¬ 
action  techniques  (sometimes  called  widgets  or 
gadgets),  such  as  menus,  scroll  bars,  and  buttons, 
along  with  a  programming  mechanism  to  create 
them.  The  Garnet  toolkit  has  allowed  us  to  quickly 
create  a  number  of  interactive  user-interface  desjgn 
tools.  It  also  provides  an  appropriate  platform  on 
which  to  investigate  novel  types  of  graphical  tools. 
This  article  concentrates  on  those  aspects  of  the 
Garnet  toolkit  that  make  it  effective  for  creating 
interactive  design  tools.  It  uses  examples  from  Gar¬ 
net's  own  design  tools  to  illustrate  how  the  various 
features  of  the  Garnet  toolkit  simplified  the  tools' 
implementation.  A  number  of  previous  articles 
have  described  Garnet  (Myers  et  al.  1990)  and  the 
design  tools  (Myers  et  al.  1989;  Vander  Zanden 
and  Myers  1990;  Myers  1991  a),  Ijut  none  have  de¬ 
scribed  in-depth  the  specific  features  of  the  toolkit 
that  were  designed  to  support  interactive  design 
tools.  Neither  have  any  of  the  previous  Garnet 
papers  discussed  how  the  components  of  the  Gar¬ 
net  toolkit  simplify  implementing  the  unique  func¬ 
tionality  required  by  interactive  design  tools. 

2  The  Garnet  project 

Garnet,  which  st.ands  for  Generating  an  .Amalgam 
of  Real-time,  Novel  Editors  and  Toolkits,  is  a  re¬ 
search  project  at  Carnegie  Mellon  University  .An 
important  goal  is  to  iiivestipatc  appropriate  foun¬ 
dations  for  the  toolkits  of  the  future  so  they  will 
be  able  to  more  effectively  support  highly  inlerac- 
livc  graphical  user-interface  software,  in  addition. 
Garnet  aims  to  create  high-level  interactive  design 
tools  to  make  user-interface  software  sicnificanlly 
easier  to  design  and  implement  by  both  program¬ 
mers  and  non-programmers. 

Garnet  contains  both  programming  and  interac 
tive  design  tools.  The  programming  tools  are  called 
the  Garnet  Toolkit,  which  is  divided  into  two 
layers.  The  tower  layer,  also  called  the  toolkit  in- 
trinsics,  provides  functionality  that  allows  widgets 
and  application-specific  graphics  to  be  created 
This  includes  the  object  system,  constraints,  input 
handling,  and  graphical  object  support.  The  Gar¬ 
net  toolkit  intrinsics  are  “look-and-feel  indepen- 
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Some  of  the  gadgets  in  the  Garnet  toolkit 
with  the  Garnet  iook-and-feel.  which  has  the 
buttons  Hoating  above  the  shadow,  and  moving  in 
"simulated  3-D"  towards  the  shadow  when 
pressed 


dent,”  which  means  that  arbitrary  graphics  and  be¬ 
haviors  can  be  implemented,  l^e  intrinsics  also 
provide  a  machine-  and  window-manager-indepen¬ 
dent  interface,  so  that  software  written  using  the 
Garnet  toolkit  intrinsics  will  run  without  change 
on  any  platform  for  which  Garnet  has  been  imple¬ 
mented.  Currently,  Garnet  runs  on  the  X  Window 
System,  but  Macintosh  and  Display  Postscript  ver¬ 
sions  are  planned. 

The  next  layer  of  the  toolkit  contains  a  “widget 
set,”  which  is  a  large  and  growing  collection  of 
menus,  buttons,  gauges,  scroll  bars  and  sliders 
(Fig.  1). 

The  interactive  Garnet  design  tools  include  Gilt, 
Lapidary,  C32,  and  a  hybrid  interactive-program¬ 
ming  tool.  Jade.  Gilt  (Myers  1991  b)  is  an  interface 
builder,  which  is  a  program  Chat  lets  the  designer 
graphically  place  user-interface  components  in  a 
window,  and  thereby  create  menus,  palettes,  and 
dialog  boxes.  Gilt  provides  most  of  the  functional¬ 
ity  found  in  other  interface  builders,  but  was  creat¬ 
ed  in  only  about  two  man-months  and  contains 
about  2700  lines  of  Lisp  code.  Lapidary  (Myers 
et  al.  1989;  Vander  Zanden  and  Myers  1991)  is  a 
esearch  vehicle  for  investigating  how  to  provide 
new  functionality  in  visual  interactive  design  tools. 
For  example,  it  lets  the  user-interface  designer 
draw  pictures  of  what  the  user  interface  should 
look  like  and  then  demonstrate  how  it  should 
change  in  response  to  user  input.  Lapidary  is  the 
only  interactive  design  tool  that  allows  the  behavior 
of  application-specific  graphical  objects  to  be  de¬ 
fined  without  writing  code.  C32  is  a  spreadsheet 
interface  for  defining  constraints  {Myers  1991  a). 


Jade  automatically  creates  menus  and  dialog  boxes 
from  a  textual  list  of  their  contents  (Vander  Zanden 
and  Myers  1990).  A  graphics  artist  can  then  modify 
bis  layout  using  a  drawing  editor,  and  Jade  will 
remember  the  changes,  even  if  the  original  textual 
specification  is  changed. 

Garnet  is  implemented  in  Common  Lisp  and  cur¬ 
rently  uses  the  X  window  manager.  Garnet  is  there¬ 
fore  portable  and  runs  on  various  machines  and 
operating  systems.  For  example.  Garnet  runs  on 
CMU,  Lucid,  Allegro,  TI,  and  Harlequin  Common 
Lisps  on  hardware  such  as  Sun,  DECStation,  TI 
and  HP.  Garnet  does  not  use  the  Common  Lisp 
Object  System  (CLOS)  or  any  Lisp  or  X  toolkit 
(such  as  Interviews  (Linton  et  al.  1989),  CLUE. 
CLIM,  or  Xtk  (McCormack  and  Asente  1988)). 
The  toolkit  layer  of  Garnet  (Myers  et  al.  1991)  and 
Gilt  have  been  released  for  general  use,  and  there 
are  over  150  licensed  universities  and  companies. 
We  expect  to  release  other  parts  shortly.’ 


3  Related  work 

The  Garnet  system  as  a  whole  is  a  user  interface 
development  environment,  which  is  sometimes 
called  a  user  interface  management  system  (UlMS). 
These  tools  have  been  surveyed  in  various  places 
(Hartson  and  Hix  1989;  Myers  1989a;  Brown  and 
Cunningham  1989). 

There  are  many  different  toolkits  available  today. 

'  Garnet  is  available  free  of  charge.  Contact  the  first  author 
for  more  information  about  obtaining  Garnet,  or  send  electron¬ 
ic  mail  to  garnet (gics.cmu.edu 
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The  most  famous  are  probably  Macintosh  Tool¬ 
box,  Windows  and  Presentation  Manager  toolkits 
for  the  PC,  and  various  X  toolkits  based  on  Xtk 
(McCormack  and  Asente  1988)  including  Motif 
and  OpenLook.  All  of  these  toolkits  provide  librar¬ 
ies  of  widgests,  but  no  support  for  handling  input 
and  output  in  the  main  application  window.  The 
NextStep  toolkit  for  the  NeXT  computer  provides 
an  object-oriented  set  of  widgets,  as  well  as  a  well- 
defin^  method  for  subclassing  the  existing  objects 
to  create  application-specific  objects.  However, 
these  objects  stiU  have  to  deal  with  all  input  and 
output  (firectly.  None  of  these  toolkits  provide  spe¬ 
cial  features  to  make  it  easy  to  create  interactive 
design  tools. 

Some  of  the  features  found  in  the  Garnet  toolkit 
have  been  used  in  previous  systems,  but  Garnet 
is  the  first  to  integrate  them  ail.  The  prototype- 
instance  model  for  objects  (Lieberman  1986)  has 
been  used  in  SELF  (Chambers  et  aL  1989).  Con¬ 
straints,  which  are  relationships  that  are  specified 
once  but  maintained  automatically  by  the  system, 
have  been  widely  used  by  research  systems  (Bom- 
ing  and  Duisberg  1986).  Constraints  can  be  either 
one-way  or  multi-way.  One-way  constraints  allow 
the  constraint  solver  to  change  only  one  of  the 
objects  in  the  constraint  in  order  to  satisfy  it;  multi¬ 
way  constraints  allow  any  of  the  objects  in  the 
constraint  to  be  changed.  Early  multi-way  con¬ 
straint  systems  include  Sketchpad  (Sutherland 
1963),  which  pioneered  the  use  of  graphical  con¬ 
straints  in  a  drawing  editor  in  the  early  1960s,  and 
Thinglab  (Boming  1981),  which  used  constraints 
for  graphical  simulation.  More  recently,  Thinglab 
has  been  refined  to  aid  in  generating  user  interfaces 
(Freeman-Benson  et  al.  1990).  CONSTRAINT 
(Vander  Zanden  1989)  provided  a  user-interface 
development  environment  that  employed  multi¬ 
way  constraints,  but  introduced  a  new  constraint¬ 
solving  algorithm  that  made  multi-way  constraints 
efficient  enough  to  be  solved  in  real  time.  Most 
systems  that  have  been  designed  for  developing 
user  interfaces  use  one-way  constraints  because  of 
their  simplicity  and  efficiency.  Grow  (Barth  1986), 
Peridot  (Myers  1988),  and  Apogee  (Henry  and 
Hudson  1988)  are  three  examples.  Grow  was  per¬ 
haps  the  first  user-interface  development  system 
that  employed  constraints.  Peridot  was  the  first  to 
try  to  infer  constraints,  and  Apogee  was  the  first 
to  employ  lazy  evaluation.  Garnet  currently  uses 
one-way  constraints,  but  a  more  powerful  model 
is  being  investigated. 
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The  event-handling  part  of  Garnet  categorizes  be¬ 
haviors  into  a  few  “ interactor"  object  types  and 
is  based  on  the  Model- View-Controller  idea  from 
SmaUtalk  (Krasner  and  Pope  1988).  However,  the 
Views  and  Controllers  tend  to  be  so  tightly  linked 
in  Smalltalk  that  the  programmer  must  program 
new  Controllers  for  most  new  objects,  whereas  in 
Garnet  programmers  rarely  need  to  program  new 
interactors.  In  addition,  Garnet’s  interactors  are 
built  into  the  toolkit,  whereas  in  Smalltalk  the  pro¬ 
grammer  must  code  the  event  handlers.  Finally, 
the  interactors  provide  a  rich  set  of  parameters  for 
customizing  their  behavior  so  that  it  is  unusual 
for  a  programmer  to  create  subclasses  of  the  built- 
in  interactor  types  (although  it  is  possible). 

Gilt,  the  Garnet  Interface  Builder,  is  very  similar 
to  other  interface  builders,  such  as  Menulay  (Bux¬ 
ton  et  al.  1983),  Trillium  (Henderson  1986),  Dialog- 
Editor  (Cartelli  1988),  vu  ^Singh  and  Green  1988), 
NeXTs  Interface  Builder,  the  Prototyper  from 
Smethers  Barnes  for  the  Macintosh,  and  UIMX 
from  Visual  Edge  for  X.  Lapidary  extends  the  ideas 
in  these  to  support  the  creation  of  widgets,  based 
on  ideas  in  Peridot  (Myers  1990a;  Myers  1988). 
Lapidary  can  also  create  application-specific 
graphics. 

C32  is  based  on  financial  spreadsheets  like 
VisiCalc,  Lotus  1-2-3,  and  Microsoft  Excel.  Other 
systems  that  have  used  spreadsheets  for  defining 
user  interfaces  include  NoPumpG  and  NoPumpII 
(Wilde  1990).  The  NoPump  systems  were  stand¬ 
alone  spreadsheets  that  were  not  integrated  with 
an  toolkit,  so  they  had  to  invent  a  constraint  solver 
and  a  way  to  handle  input,  which  the  Garnet  tool¬ 
kit  provides  to  C32. 

4  Garnet  interactive  design  tools 

This  section  describes  several  of  the  interactive  de¬ 
sign  tools  built  by  the  Garnet  group.  Some  external 
users  have  also  built  interactive  design  tools  on 
top  of  Garnet  [for  example.  Humanoid  (Szekely 
1990)].  Later  sections  will  illustrate  how  various 
features  of  the  Garnet  toolkit  simplified  the  con¬ 
struction  of  these  tools. 

4.1  Gilt 

Gilt,  the  Garnet  Interface  Layout  Tool,  is  a  simple 
widget  layout  tool  patterned  after  the  NeXT  inter- 
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face  builder.  It  is  intended  to  help  create  dialog 
boxes  that  do  not  change  size  and  whose  contents 
do  not  change  dynamically  (although  the  widgets 
can  “grey  out”  when  not  valid).  Gilt  supplies  a 
palette  of  the  builMn  Garnet  widgets  (either  with 
the  Garnet  or  Motif  look-and>feel)  plus  rectangles, 
lines,  text  labels,  and  bitmaps  to  be  used  as  decora¬ 
tions.  The  user  can  select  objects  in  the  palette  and 
plate  them  in  a  workspace  window  (Fig.  2).  Objects 
in  the  workspace  window  can  be  selected,  moved 
or  changed  in  size,  their  text  labels  changed,  and 
their  other  properties  set.  Commands  for  duplicat¬ 
ing  and  deleting- objects  are  provided.  There  is  also 
an  Align  command,  which  adjusts  objects’  position 
and  spacing. 

If  the  user  needs  a  more  dynamic  interface,  for  ex¬ 
ample  to  have  one  object’s  property  tied  to  an¬ 
other’s,  the  code  generated  by  Gilt  can  be  edited 
using  a  text  editor,  or  read  into  Lapidary  (because 
all  the  tools  use  the  same  Hie  format). 


4.2  Lapidary 

Lapidary  is  a  graphical  interactive  design  tool  that 
allows  users  to  pictorially  specify  ail  graphical  as¬ 
pects  of  an  application,  including  the  widgets  that 
surround  application  windows  and  the  objects  and 
behaviors  that  go  inside  application  windows 
(Myeis  et  al.  1989;  Vander  Zanden  and  Myers 
1991).  Lapidary  is  an  acronym  that  stands  for  Lisp- 
based  Assistant  for  Prototyping  Interactive  De¬ 
signs  Allowing  gemarkable  Yield- 
Many  of  the  windows  that  comprise  the  Lapidary 
interface  are  shown  in  Fig.  3.  Lapidary  provides 
a  direct-manipulation  drawing  editor  that  allows 
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users  to  create  objects  from  scratch,  such  as  the 
floating  button  menu  in  Fig.  3,  or  edit  instances 
of  objects  created  from  prototypes  in  libraries.  A 
set  of  iconic  constraint  menus  allow  users  to  posi¬ 
tion  objects  in  a  scene.  If  users  cannot  And  the 
constraint  they  need,  the  customize  button  can  be 
hit  to  gain  access  to  the  C32  spreadsheet  described 
in  Sect  4.3.  Users  can  specify  behaviors  either 
through  dialog  boxes  or  via  demonstration. 


4.3  C32 

C32  is  a  spreadsheet  interface  for  defining  complex 
constraints  (Myers  1991  a).  C32  stands  for  CMU’s 
Qlever  and  Compelling  Contribution  to  Consputer 
Science  in  ConuQonLisp,  which  is  Customizable 
and  Ch^^cterized  by  a  Coniplete  Coverage  of 
Code  and  Contains  a  Cornucopia  of  Creative  Con¬ 
structs,  because  it  Can  Create  Complex,  Correct 
Constraints  that  are  Constructed  Qearly  and  Con¬ 
cretely,  amd  are  Communicated  using  Columns  of 
Cells  that  are  Constantly  Calculated  so  they 
Change  Continuously  and  Cancel  Confusion. 

The  intention  is  that  the  Lapidary  icons  or  a  simi¬ 
lar  mechanism  can  be  used  for  simple  constraints, 
but  sometimes  the  user  will  need  more  complex 
relationships.  C32  provides  the  same  benefits  for 
constraint  definition  as  conventional  spreadsheets 
provide  for  financial  operations.  Some  features  of 
C32  are: 

-  The  current  values  of  the  constraints  are  visible 
and  are  updated  immediately  if  the  associated 
graphical  object  changes,  either  due  to  the  user 
interacting  with  the  graphics  or  some  program 
changing  a  value.  This  makes  the  results  of  the 
constraints  visible  and  therefore  more  understand¬ 
able. 

-  Menus  provide  the  most  common  functions  that 
might  be  inserted  into  constraints,  so  users  do  not 
have  to  know  the  function  syntax. 

-  Object  and  slot  references  arc  automatically  gen¬ 
erated,  so  users  do  not  have  to  know  the  syntax 
for  references  or  the  particular  form  the  reference 
should  take  (objects  can  be  referenced  directly  by 
name  or  indirectly  through  their  position  in  the 
aggregate  hierarchy  and  C32  figures  out  which  is 
more  appropriate).  The  user  can  select  the  referent 
either  by  pointing  to  a  C32  spreadsheet  cell  or  just 
by  pointing  to  the  actual  graphical  object  in  a  Gar¬ 
net  window. 
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Fig.  3a-k  Various  Lapidary  windows.  The  drawing  window  (c) 
contains  floating  buttons  for  a  color  menu.  The  comtraint  menu 
below  it  (g)  has  been  used  to  align  the  objects  within  each 
button,  the  items  within  the  menu,  and  the  black  xor  rectangle, 
which  is  the  final  feedback  (currently  over  "Orange").  The  dialog 
box  in  the  lower-left  comer  (f)  defines  the  menu  behavior  by 

-  C32  guesses  how  to  parameterize  constraints 
when  they  are  copied  from  one  place  to  another 
or  generalized  into  procedures,  so  abstract  and  re¬ 
usable  constraints  can  be  constructed  by  example. 

-  Graphical  techniques  are  used  to  help  trace  and 
debug  constraints. 

Each  object  has  its  own  column  in  the  spreadsheet, 
with  the  rows  showing  the  values  of  each  of  the 
slots.  Icons  are  used  to  show  whether  a  slot  is  in¬ 


indicating  that  the  behavior  will  apply  (c  (he  objects  in  color- 
menu-items  and  that  the  final  feedback  will  be  the  black  xor 
rectangle.  The  window  in  the  upper-left  comer  (a)  contains  the 
main  Lapidary  commands,  and  the  remaining  windows  contain 
geometric  properties  that  may  be  set  in  Lapidary 


herited  and  whether  it  is  calculated  using  a  con¬ 
straint.  Figure  4  shows  an  example. 


4.4  Jade 

While  Jade  is  only  partially  interactive,  it  is  inter¬ 
esting  how  it  uses  the  features  of  the  Garnet  toolkit. 
Jade  (a  Judgement-based  Automatic  Qialog  Edi¬ 
tor)  takes  a  textual  specification  of  a  dialog  and 
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Rt.4.  C32  viewing  three  objects.  The  scroll  bars  can  be  used 
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means  that  the  slot  value  is  computed  with  a  formula  Icon- 
straint).  All  inherited  slots  are  shown  in  italics  and  marked 
with  the  (D  icon.  When  a  formula  is  inherited,  the  icon  is  next 


automatically  generates  a  dialog  box  (Vandet  Zan- 
den  and  Myers  1990).  It  is  typically  used  when 
it  is  too  inconvenient  to  use  Gilt  or  Lapidary,  for 
example  when  an  interface  has  dozens  of  dialog 
boxes.  A  graphics  artist  can  use  a  direct  manipula¬ 
tion  editor  to  add  decorations  or  modify  the  layout 
created  by  Jade,  and  Jade  will  remember  the 
changes,  even  if  the  underlying  textual  specification 
is  modified.  A  sample  dialog  and  its  textual  specifi¬ 
cation  is  shown  in  Fig.  S.  In  laying  out  the  dialog. 
Jade  consults  designer-provided  look-and-feel  and 
rule  libraries.  The  look-and-feel  libraries  help  Jade 
decide  which  gadgets  should  be  associated  with 
various  elements  of  the  textual  specification.  For 
example,.  Jade  has  selected  a  Gamet-styie  radio 
button  in  Fig.  5  a  and  an  Open  Look-style  widget 
in  Fig.  5  b  to  represent  a  single-choice  behavior. 
The  gadgets  for  the  look-and-feel  libraries  can  be 
created  using  Lapidary  or  C32.  Jade  uses  the  rule 
libraries  to  help  it  lay  out  the  dialog  box.  In  the 
future,  we  plan  to  develop  an  interactive  design 
tool  that  allows  graphics  artists  to  define  rules  by 
example,  perhaps  by  applying  constraints  to  an  ex¬ 
ample  object. 

5  Toolkit  properties 

Many  features  of  the  Garnet  toolkit  were  added 
specifically  to  make  it  easier  to  create  highly  inter¬ 


to  the  formula  icon  and  the  value  is  shown  in  a  regular  font. 
This  is  because  the  value  is  usually  different  from  the  proto¬ 
type's.  For  example,  the  ;  width  slot  of  a  text  object  usually 
contains  a  formula  that  computes  the  width  based  on  the  ob¬ 
ject's  font  and  siring  value.  Most  text  objects  inherit  this  formu¬ 
la,  but  still  have  a  different  current  value,  because  their  string 
and  font  values  are  different 


active  user  interfaces,  such  as  the  interfaces  of  visu¬ 
al  interactive  design  tools.  These  include: 

-  Use  of  a  prototype-instance  object  system  in¬ 
stead  of  the  usual  class-instance  model. 

-  Integration  of  constraints  with  the  object  system. 
Graphics  model  that  supports  automatic  graphi¬ 
cal  update. 

-  Separation  of  specifying  the  graphics  of  objects 
from  specifying  the  behavior. 

'  Support  for  saving  objects  on  the  screen  or  in 
memory  to  disk  as  text  files  in  a  way  that  they 
can  be  read  back  into  the  system. 

-  Automatic  layout  of  graphical  objects  in  a  vari¬ 
ety  of  styles,  such  as  rows,  columns,  tables,  trees, 
and  graphs. 

-  Widget  set  that  supports  such  commonly  used 
operations  as  selection,  moving,  and  growing  ob¬ 
jects  and  displaying  and  setting  their  properties. 

Several  of  the  features  contain  innovations,  such 
as  structural  inheritance  in  the  prototype-instance 
system,  pointers  in  the  constraint  system,  an  inte¬ 
gration  of  constraints  with  an  automatic  graphical 
update  system,  interactors  model  for  separating 
graphics  from  behavior,  and  a  method  for  minimiz¬ 
ing  the  amount  of  information  written  to  disk  when 
saving  objects.  Other  features,  such  as  automatic 
layout  and  widget  set  are  not  novel  but  they  are 
useful  in  creating  interactive  design  tools.  The  fol¬ 
lowing  sections  discuss  these  features  in  detail. 
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Fig.  Sa-c.  Alternative  Garnet  a  and  OpenLook  b 
style  dialogs  for  specifying  the  properties  of  a 
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5.1  Prototype-instance  model 

5.1.1  General  description 

The  Garnet  object-oriented  programming  system 
supports  a  prototype-instance  model,  rather  than 
the  conventional  class-instance  model  used  by 
most  other  object  systems,  such  as  Smaili;ilk, 
C-l- +,  and  CLOS.  In  a  prototype-instance  model, 
them  is  no  distinction  between  instances  and  class¬ 
es;  any  instance  can  serve  as  a  ‘‘prototype”  for 
other  instances  (even  an  object  that  is  b^g  dL- 
played  on  the  screen  can  be  a  prototype). 

All  dau  and  methods  are  stoi^  in  “slots”  (some 
times  called  fields  or  instance  variables).  Slots  that 
are  not  overridden  by  a  particular  instance  inherit 
their  values  from  their  prototypes.  There  is  no' dis¬ 
tinction  between  data  and  method  slots  in  Garnet 
Any  slot  can  hold  any  type  of  value,  and  in  Com¬ 
mon  Lisp  a  function  is  just  a  type  of  value  Slot 
oames  can  contain  any  number  of  printing  charac¬ 
ters  (eg.,  left,  interim— selected,  obj-- 
over). 

An  instance  can  also  add  any  number  of  new  slots. 
Unlike  conventional  class-instance  models,  this 
means  that  the  number  of  slots  in  each  object  is 
variable  -  each  object  can  have  a  different  number 
of  local  slots,  depending  on  which  properties  it 
wants  to  inherit  defaults  for  and  which  it  wants 
to  override.  Moreover,  the  number  of  slots  of  an 
object  can  even  change  dynamically.  Slots  can  be 
explicitly  removed  from  objects  at  any  time.  Also, 
if  a  program  sets  the  value  of  a  slot  that  does  not 
exist,  then  the  slot  is  created  automatically.  If  a 
program  asks  for  the  value  of  a  slot  that  does  not 
exist,  NIL  is  returned  (there  is  a  function  that  tests 
whether  a  slot  exists).  All  slots  are  untyped. 

The  efficiency  of  Garnet’s  object  system  is  actually 
better  than  other  class-based  Lisp  object  systems, 
such  as  CLOS.  For  example,  on  a  Sun  SPARCsta- 
tion  1  running  Allegro  Common  Lisp,  the  simplest 
slot  accessor  function  takes  two-  and  one-half  times 
as  long  in  CLOS  (23.7  microseconds),  than  in  Gar¬ 
net  (9.5  microseconds).  To  create  an  instance  in 
CLOS  (3486  microseconds)  takes  about  eight  times 
longer  than  in  Garnet  (433  microseconds). 

A  unique  feature  of  the  Garnet  object  system  is 
the  support  for  structural  inheritance.  Objects  can 
be  grouped  into  an  “aggregate”  object.  Then  this 
aggregate  can  be  used  as  a  prototype  for  new  ob¬ 
jects  in  the  same  ’  .y  as  a  primitive  object  can 
be.  When  an  instance  is  made  of  an  aggregate,  Gar- 
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net  automatically  creates  instances  of  aU  the  parts 
and  links  them  together  in  the  appropriate  manner. 
Edits  made  to  the  prototype  are  automatically  re¬ 
flected  in  all  instances.  For  example,  if  objects  are 
added  or  removed  from  the  prototype,  the  same 
edit  is  made  to  ail  the  instances  of  that  prototype 
(see  Fig.  6). 

V-'i  function  that  adds  a  new  object  to  an  aggre¬ 
gate  takes  an  optional  locator  argument  (e.g.,  front, 
back,  before  obj,  after  obj)  to  determine  where  to 
insert  the  object  with  respect  to  the  other  children 
of  that  aggregate  (which  is  important,  because  the 
order  determines  the  back-to-front  drawing  order 
and  therefore  which  objects  are  covered  by  other 
objects).  After  the  object  is  inserted  into  the  aggre¬ 
gate,  Garnet  checks  a  special  slot,  which  contains 
a  list  of  all  the  instances  of  the  aggregate.  For  each 
instance  of  the  aggregate.  Garnet  creates  an  in¬ 
stance  of  the  inserted  object  and  inserts  the  new 
instance  into  the  insunce  aggregate.  Instances  of 
the  inserted  object  that  are  propagated  to  an  aggre¬ 
gate’s  instances  are  also  positioned  using  the  lo¬ 
cator  argument.  If  the  locator  specified  that  the 
added  object  should  be  inserted  before  or  after  a 
child.  Garnet  finds  the  instance  of  this  child  in  each 
of  the  aggregate’s  instances  and  then  inserts  an  in¬ 
stance  of  the  added  objea  in  the  appropriate  spot 
When  an  object  is  removed  from  an  aggregate. 
Garnet  first  removes  the  object  from  the  aggre¬ 
gate’s  components  list,  then  removes  instances  of 
the  object  from  each  of  the  aggregate’s  instance- 
components  list. 


Fig.  Si,  b.  Before  a  and  after  b  editing  a  prototype. 
When  the  prototype  (shown  on  the  left)  is  edited  to 
change  the  font  to  italic  and  add  a  shadow,  the 
modiftcatioas  are  immediately  reflected  in  all  of  the 
instances  (shown  on  the  right!.  Note  that  the  sues  of 
the  boxes  change  in  b  because  the  font  width  is 
smaller 
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If  the  programmer  wants  the  new  object  to  be  inde¬ 
pendent  of  the  prototype  (so  that  edits  to  the  proto¬ 
type  do  not  affect  the  instance),  then  the  built-in 
copy  function  can  be  used  instead  of  the  instancing 
function.  The  lesulting  object  will  look  the  same 
as  an  instance,  but  there  will  not  be  any  back  point¬ 
ers. 


S.1.2  Saving  and  restoring  objects 

Another  very  important  feature  of  the  Garnet  ob¬ 
ject  system  is  that  there  is  built-in  support  for  sav¬ 
ing  and  restoring  objects  to  the  disk.  A  single  Gar¬ 
net  function  takes  an  in-memory  or  on-screen  ob¬ 
ject  and  writes  it  to  a  disk  file  in  a  format  that 
can  later  be  read  in  again.  If  the  object  is  an  aggre¬ 
gate,  then  all  the  parts  are  written  to  the  file  also. 
Direct  pointer  links  among  objects  are  automati¬ 
cally  converted  to  indirect  references  so  that  no 
actual  pointers  will  be  written  to  the  disk.  Con¬ 
straints  (see  Sect.  S.2)  are  also  output  in  an  appro¬ 
priate  form. 

In  addition  to  the  convenience  of  having  saving 
and  restoring  code  provided  to  applications,  pro¬ 
viding  a  central  mechanism  simplifies  the  imple¬ 
mentation  of  interactive  design  tools.  The  tools  can 
create  whatever  structures  they  want  without  hav¬ 
ing  to  worry  about  converting  these  structures  to 
a  suitable  external  structure,  because  the  built-in 
save-restore  mechanism  can  write  out  all  Garnet 
objects. 

Due  to  the  tree  structure  of  aggregates  (aggre¬ 
gates  contain  primitive  objects  and  other  aggre¬ 
gates,  which  themselves  may  contain  objects  and 
aggregates),  it  is  economical  to  save  them  using 
a  tree-structured  format,  listing  only  parts  and  slots 
that  override  defaults  defined  by  the  prototype. 
First,  the  differences  between  each  object  and  its 
prototype  are  computed.  Inasmuch  as  an  object 
can  add,  remove,  or  even  override  the  children  it 
inherits  from  its  prototype,  these  differences  may 
include  structural  differences  as  well  as  simple 
value  differences.  Only  these  differences  and  the 
name  of  the  prototype  are  needed  to  reconstruct 
a  copy  of  the  object.  If  there  a  j  structural  differ¬ 
ences,  Garnet  writes  out  commands  that  tell  the 
object-creation  mechanism  how  to  create  addition¬ 
al  children,  override  existing  children,  or  omit  cer¬ 
tain  children.  By  writing  out  only  the  differences 
rather  than  the  complete  structure  of  each  instance, 
the  programmer  is  able  to  understand  and  change 
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the  generated  code  more  easily  and  the  code  is 
shorter  and  more  efficient. 

The  output  file  is  simply  the  Lisp  code  to  create 
the  objects.  Therefore,  when  the  code  is  loaded  by 
an  application  or  by  an  interactive  design  tool,  the 
objects  will  be  created  The  prototype-instance  ob¬ 
ject  system  allows  a  tool  to  modify  the  objects  in 
memory,  which  means  that  it  is  never  necessary 
for  the  tool  to  look  at  or  parse  the  gen‘  •■ated  file. 
Generated  files  are  in  exactly  the  same  form  as 
the  code  that  a  programmer  would  write  by  hand 
to  create  the  same  objects.  Therefore,  no  special 
mechanism  is  needed  to  read  objects  in  again:  the 
standard  Lisp  loading  function  is  sufficient.  Neither 
special  formats  for  output,  such  as  UlL  for  the 
Motif  toolkit,  nor  associated  parsers,  are  needed. 
Programmers  of  design  tools  do  not  need  to  write 
code  generators,  as  in  most  other  systems,  because 
the  built-in  Garnet  function  can  be  used.  The  stan¬ 
dard  Lisp  compiler  can  also  be  used  to  make  the 
generated  files  more  efficient. 

In  addition,  because  the  generated  object  descrip¬ 
tions  are  standard  Lisp  using  the  conventional 
Garnet  style  and  functions,  it  is  very  easy  for  pro¬ 
grammers  to  read  the  code  to  make  sure  that  it 
is  correct.  It  is  also  possible  to  directly  modify  the 
code  using  a  text  editor  if  necessary.  Inasmuch  as 
Garnet  requires  no  special  mechanism  to  read  the 
code,  the  programmer  is  fret  to  make  arbitrary 
edits  and  the  file  will  still  be  loadable  (assuming 
the  edits  do  not  introduce  errors,  of  course).  For 
example,  the  programmer  could  add  or  subtract 
children  from  an  aggregate,  add  new  slots  for  spe¬ 
cial  processing,  write  complex  constraints  that  can¬ 
not  be  expressed  using  the  design  tools,  and  even 
add  or  delete  new  objects.  In  addition,  because  the 
programmer’s  changes  will  be  reflected  in  the  m- 
memory  versions  of  the  objects  after  the  code  is 
loaded  into  a  design  tool,  these  edits  will  be  pre¬ 
served  when  the  files  are  written  out  again. 

Because  interactive  design  tools  are  only  capable 
of  specifying  certain  types  of  objects  and  behaviors, 
there  are  cases  when  a  programmer  will  need  to 
edit  the  code  created  by  the  design  tool  in  order 
to  achieve  the  desired  functionality  for  an  interface. 
Thus,  it  is  important  that  the  programmer  be  able 
to  modify  the  generated  code  and  still  be  able  to 
operate  on  the  objects  and  behavior  using  the  de¬ 
sign  tools.  Garnet’s  ability  to  create  code  in  the 
language  used  by  the  programmer  without  having 
to  resort  to  special  or  binary  representations  is 
therefore  an  important  advantage  when  creating 
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new  interactive  design  tools.  Because  the  code  can 
be  compiled,  there  is  also  no  efliciency  penalty  for 
this. 

Both  Lapidary’s  and  Gilt’s  implementation  are 
substantially  simplified  by  this  save-restore  facility. 
When  either  tool  wants  to  save  an  object,  behavior, 
or  window  to  disk,  they  first  write  some  standard 
header  information  to  the  file,  and  then  call  the 
Garnet  object-writing  function  on  the  entire  win¬ 
dow.  As  long  as  programmers  do  not  change  the 
header  (which  they  have  no  reason  to  do),  both 
tools  can  read  a  file  simply  by  using  the  Lisp 
“load”  function. 

Another  advantage  of  the  simple  format  for  the 
generated  code  is  that  it  is  possible  to  write  compil¬ 
ers  that  optimize  the  generated  objects,  for  example 
by  removing  extraneous  slots  or  constraints  that 
a  tool  may  have  inserted  for  its  own  use.  This  can 
improve  the  efficiency  of  the  applications  that  use 
the  objects. 


5.1.3  Uses  of  the  prototype-instance  model  in  de¬ 
sign  tools 

The  use  of  a  prototype-instance  model  has  a  large 
number  of  significant  advantages  for  interactive  de¬ 
sign  tools. 

5. 1.3.1  Dynamic  editing.  In  conventional  class-in¬ 
stance  object  systems,  it  is  very  expensive  to  modify 
classes.  If  there  are  existing  instances  of  the  classes 
in  memory,  then  modification  is  often  not  even  al¬ 
lowed  (for  example  in  C  ■♦>  + ).  Instead,  the  in¬ 
stances  must  be  destroyed,  classes  recompiled,  and 
then  new  instances  must  be  created.  Even  in  sys¬ 
tems  that  permit  class  evolution,  the  data  struc¬ 
tures  representing  the  instances  are  semi-compiled 
and  must  be  redone  if  classes  are  allowed  to  change. 
Thus,  something  as  simple  as  adding  a  new  instance 
variable  to  all  objects  in  a  class  while  the  objects 
are  being  viewed  is  either  very  expensive  or  impos¬ 
sible  in  most  systems.  This  makes  it  very  difficult 
to  create  an  editor  that  will  allow  dynamic  proto¬ 
typing  and  editing  of  objects  and  their  structure. 
The  dynamic  editing  capabilities  of  the  Garnet  pro¬ 
totype-instance  model  clearly  makes  it  ideal  for 
prototyping  systc.-  .a.  An  interactive  design  tool  can 
simply  provide  mechanisms  for  the  user  to  add  and 
remove  slots,  objects,  and  properties  from  objects. 
If  the  user  happens  to  modify  a  prototype  object, 
then.  Garnet  insures  that  all  instances  are  updated 
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appropriately.  The  very  same  editing  operations 
can  be  used  on  prototypes  and  on  instances,  both 
from  the  user’s  and  the  tool  implcmenter’s  point 
of  view,  and  Garnet  takes  care  of  the  bookkeep¬ 
ing. 

As  an  example.  Lapidary  uses  the  prototype-in¬ 
stance  model  to  allow  users  to  dynamically  create 
and  modify  objects.  Initially,  objects  are  created 
with  only  a  basic  set  of  graphical  slots,  methods, 
and  components.  Users  can  then  attach  constraints 
and  behaviors  and  add  or  subtract  objects.  If  the 
components  of  a  prototype  are  modified,  the  modi¬ 
fications  will  be  immediately  propagated  to  all  in¬ 
stances,  thus  allowing  the  user  to  immediately  see 
the  new  look  in  context.  This  form  of  structural 
inheritance  is  unique  among  interface  builders.  For 
example,  users  can  make  the  edits  shown  in  Fig.  6 
using  Lapidary. 

5.1. 3.2  Creation  of  prototypes.  The  lack  of  dis¬ 
tinction  between  prototypes  and  instances  also 
means  that  interactive  design  tools  can  easily  pro¬ 
vide  a  mechanism  for  users  to  make  libranes  of 
objects.  The  tool  can  allow  the  user  to  select  an 
object  (which,  of  course,  may  be  an  aggregate  of 
other  objects)  and  use  that  object  as  a  prototype. 
The  prototypes  might  be  collected  together  in  a 
window  to  form  a  “style  sheet."  The  user  can  then 
use  instances  of  the  prototype  in  application  win¬ 
dows.  If  the  user  decides  that  the  prototype  does 
not  look  or  operate  correctly,  the  prototype  can 
be  edited  (which  will  also  change  ail  the  instances) 
so  the  user  can  sec  immediately  how  ail  the  in¬ 
stances  will  look  in  context.  In  a  similar  way,  a 
palette  for  the  final  program  can  be  created  interac¬ 
tively  in  the  design  tool.  The  palette  will  contain 
prototype  objects  created  using  the  design  tool  and 
the  program  will  only  need  to  create  an  instance 
of  the  appropnate  one  when  the  end  user  wants 
a  new  object. 

It  is  this  ability  to  create  prototypes  on  the  fly 
that  allows  the  Lapidary  tool  to  create  application- 
specific  graphical  objects.  If  the  user  is  designing 
a  graph  editor  with  nodes  and  arcs,  some  graphical 
objects  can  be  drawn  to  represent  a  node,  these 
can  be  collected  into  an  aggregate,  and  then  that 
aggregate  used  as  a  prototype  for  all  the  nodes. 
The  application  program  then  only  needs  to  create 
instances  of  the  node  prototype,  and  does  not  need 
to  know  anything  about  its  internal  graphical  ap¬ 
pearance  or  structure  (it  might  be  a  single  rectangle 
or  a  whole  collection  of  objects). 
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5.1. 3.3  Adding  new  slots.  The  ability  to  add  new 
slots  to  existing  objects  is  quite  useful  for  interac¬ 
tive  design  tools.  For  example,  the  tool  might  want 
to  store  information  about  how  the  objects  were 
created,  determine  how  the  object’s  properties  were 
set,  or  save  the  previous  values  of  properties  to 
support  undo.  Even  if  the  objects  are  primitive  ob¬ 
jects,  such  as  rectangles  and  text,  or  instances  of 
predefined  widgets  from  a  library,  the  tool  caitsim- 
ply  create  new  slots  in  the  objects  using  slot  names 
that  are  meaningful  to  the  tool.  Because  messages 
are  simply  function  values  in  slots,  new  messages 
can  just  as  easily  be  added  to  pre-existing  objects. 
No  new  “classes”  are  needed.  Thus,  a  design  tool 
can  add  tool-specific  methods,  such  as  a  custom 
destroy  method. 

These  new  slots  that  the  tool  creates  can  be  written 
out  to  the  disk  with  the  rest  of  the  objects.  This 
is  very  useful  if  the  slots  contain  status  or  identifica¬ 
tion  information  that  the  tool  needs  when  reading 
the  objects  in  again  Alternatively,  the  tool  imple- 
menter  can  declare  that  these  extra  slots  should 
not  be  written  out  with  the  objects. 

Lapidary  makes  use  of  the  ability  to  add  and  delete 
slots  both  to  support  itself  and  to  support  behav¬ 
iors  added  to  the  objects.  For  example,  it  adds 
the  objover  slot  to  feedback  objects  so  that  they 
can  indirectly  reference  the  object  they  should 
highlight.  Lapidary  also  adds  slots  to  support  indi¬ 
rect  references  to  objects  and  offsets  in  its  position¬ 
ing  and  sizing  constraints.  For  example,  to  support 
a  constraint  that  aligns  the  left  side  of  an  object 
with  the  side  of  another  object.  Lapidary  adds  an 
objover  slot  to  reference  the  other  object  and 
a  left— offset  slot  to  reference  the  size  of  the 
offset.  The  use  of  indirection  through  these  slots 
allows  Lapidary  to  support  the  fine-tuning  of  a 
constraint  without  having  to  destroy  and  recreate 
it  each  time  a  user  changes  an  offset  or  a  target 
of  the  constraint.  Before  saving  a  set  of  objects. 
Lapidary  removes  its  support  slots  so  they  will  not 
clutter  up  the  generated  code.  Similarly,  Lapidary 
reinstalls  these  slots  when  the  objects  are  loaded 
later. 


5.1. 3.4  Dynamic  leading.  Another  important  fea¬ 
ture  of  the  object  system  is  that  single  objects  or 


^  in  this  case,  the  programmer  would,  of  course,  have  to  be 
careful  to  preserve  this  information  if  hand-editing  of  the  gener¬ 
ated  code  was  necessary 


groups  of  objects  can  be  dynamically  loaded  at 
any  time.  Garnet  requires  that  the  prototype  for 
objects  be  loaded  before  any  instances  of  that  pro¬ 
totype  are  used,  but  it  is  easy  to  insure  that  the 
files  that  create  instances  automatically  load  the 
prototypes  first,  if  they  are  not  already  loaded. 
Dynamic  loading  can  also  be  used  to  reduce  the 
memory  size  of  applications.  For  example.  Gilt 
uses  bitmap  pictures  to  represent  the  widgets  that 
can  be  loaded.  The  first  time  that  a  particular  type 
of  widget  is  needed.  Gilt  simply  loads  the  prototype 
and  creates  an  inst?.nce  of  it.  Many  of  the  large 
and  complicated  widgets  are  not  needed  by  most 
users,  and  so  they  do  not  need  to  ever  be  loaded. 


5.2  Constraints 

Garnet  provides  constraints  that  allow  program¬ 
mers  to  specify  relationships  between  objects  that 
are  automatically  maintained  by  a  constraint 
solver.  The  relationships  expressed  by  constraints 
may  be  graphical,  for  example,  to  position  a  check¬ 
mark  next  to  a  set  of  menu  items,  or  non-graphical, 
for  example,  to  make  the  selected  item  in  a  proper¬ 
ty  menu  (e.g,,  a  line  style)  match  the  corresponding 
property  in  the  selected  object.  The  contents  of  an 
object’s  slot  can  be  an  ordinary  value,  such  as  a 
number  or  string,  or  they  can  be  a  constraint  that 
calculates  the  value.  When  the  value  of  the  slot 
is  requested.  Garnet  will  automatically  evaluate  the 
constraint  and  return  the  calculated  value. 

Garnet  constraints  are  arbitrary  pieces  of  Lisp 
code.  They  may  be  thought  of  as  functions  that 
take  a  set  of  slots  as  parameters  and  return  a  result. 
Hence,  they  are  one-way  constraints.  The  con¬ 
straint-solver  is  responsible  for  detecting  changes 
to  the  slots  referenced  by  a  constraint  and  re-evalu- 
ating  that  constraint  automatically.  Both  eager  and 
lazy  algorithms  for  implementing  the  constraint 
solver  are  presented  in  Vander  Zanden  et  al. 
(1991). 

A  novel  feature  of  Garnet  is  that  programmers  can 
write  constraints  that  indirectly  reference  other  ob¬ 
jects  through  pointer  variables  and  that  these  vari¬ 
ables  can  be  changed  under  program  control  at 
runtime.  For  example,  suppose  a  checkmark 
should  be  able  to  appear  next  to  any  item  in  a 
menu.  A  programmer  could  create  this  behavior 
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by  inserting  the  following  constraint  in  the  left 
slot  of  checkmark:^ 

chtekmark. left>s«lf-ob jovar. right*10 

The  reference  self,  objover.  right  causes  the 
constraint  solver  to  consult  the  objover  slot  in 
the  current  object  (in  this  case,  the  check  mark). 
The  constraint  solver  will  then  request  the  value 
of  the  right  slot  in  the  object  contained  in  the 
slot  named  objover. 

The  use  of  pointer  variables  considerably  simplifies 
the  conversion  of  example  objects  to  prototypes 
as  well  as  several  other  features  of  interactive  de¬ 
sign  tools  (see  Sect.  5.2.1).  It  also  provides  the  full 
power  of  procedural  abstraction  in  constraints. 
Each  constraint  is  equivalent  to  a  procedure  that 
may  be  called  with  a  new  set  of  arguments  on  each 
invocation.  Previous  constraint  systems  have  al¬ 
lowed  regular  variables,  but  not  pointer  variables 
(Vander  Zanden  ei  al.  1991).  For  example,  the  10- 
pixel  offset  could  be  made  into  a  variable  called 
offset,  but  the  reference-  objover  would  not 
be  permissable  in  other  systems.  If  the  programmer 
wanted  the  10-pixel  offset  to  be  a  variable  in  Gar¬ 
net,  he  could  rewrite  the  constraint  as  self, 
objover.  right  +  self.  offset,  which  would 
cause  the  constraint  solver  to  look  for  the  value 
of  offset  in  the  object  that  contained  the  con¬ 
straint. 

Constraints  are  first-class  objects,  just  like  any 
other  object  in  Garnet  A  constraint  object  con¬ 
tains  slots  that  contain  a  pointer  to  the  constraint's 
lisp  code,  the  value  last  computed  by  the  con¬ 
straint,  an  indication  of  whether  this  value  is  up-to- 
date,  and  the  object  and  slot  to  which  this  con¬ 
straint  is  attached.  A  design  tool  is  free  to  add 
other  slots  to  this  constraint  object  that  will  assist 
the  design  tool  in  determining  the  type  of  this  con¬ 
straint  or  other  relevant  information.  Like  other 
objects,  constraints  may  serve  as  prototypes.  An 
instance  of  a  constraint  will  inherit  the  pointer  to 
its  function,  thus  allowing  multiple  constraints  to 
use  the  same  piece  of  code. 

Representing  constraints  as  objects  and  allowing 
pointer  variables  simplifies  the  integration  of  con¬ 
straints  with  the  prototype-instance  system.  When 
Garnet  makes  an  instance  of  a  prototype,  it  exam- 

^  For  (he  sake  of  readabiliiy,  we  are  expressing  constraints 
in  a  more  conventional  infix  notation  rather  than  Lisp's  prefix 
notation.  In  Garnet,  this  constraint  would  actually  be  wntten 
as  (+(gv  :  self  ;  objover  :  right)  10)  where  gv  stands 
for  get  valut 
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ines  each  of  the  slots  in  the  prototype,  and  if  a 
slot  contains  a  constraint,  places  an  instance  of 
that  constraint  in  the  corresponding  slot  of  the  new 
instance  object. 

If  the  prototype  is  an  aggregate.  Garnet  creates 
pointers  in  the  aggregate  to  each  child  and  back- 
pointers  in  each  child  to  the  aggregate.  For  exam¬ 
ple,  the  thermometer  aggregate  in  Fig.  7  has  point¬ 
ers  to  its  bulb,  shaft,  and  mercury  stored  in  the 
slots  bulb,  shaft,  and  mercury  respectively. 
Similarly,  each  of  the  thermometer’s  children  have 
a  pointer  to  the  thermometer  stored  in  their  par¬ 
ent  slot  Constraints  in  any  object  in  an  aggregate 
can  therefore  reach  any  other  object  by  traversing 
the  aggregate  hierarchy  using  the  appropriate  set 
of  pointers.  For  example,  the  mercury  needs  to 
know  the  position  and  size  of  the  shaft  in  order 
to  position  itself  in  the  shaft.  It  can  access  these 
values  through  the  parent  and  shaft  pointers 
(e.g., mercury.  left  = 

self,  parent,  shaft,  left). 

By  referencing  other  objects  in  the  aggregate  hier¬ 
archy  indirectly  via  pointers,  the  programmer  can 
ensure  that  the  constraints  in  instances  of  proto¬ 
types  will  automatically  reference  the  appropriate 
information.  Thus,  Garnet  is  able  to  implement  the 
instancing  of  aggregate  objects  simply  by  creating 
instances  of  each  of  the  components  of  the  aggre¬ 
gate  hierarchy,  creating  instances  of  constraints  in 
constrained  slots  and  creating  the  appropriate  set 
of  pointers.  It  is  not  necessary  to  modify  the  code 
of  the  constraints  themselves. 


5.2,1  Advantages  of  constraints 

Constraints  are  appealing,  because  they  declarati- 
vely  describe  relationships  between  a  program’s  en¬ 
tities.  A  constraint  solver  automatically  keeps  the 
constraints  satisfied,  thus  propagating  changed 
data  to  the  appropriate  locations.  In  constructing 
interactive  design  tools,  constraints  can  be  used 
to  specify  the  graphical  layout  of  the  tools’  objects 
and  the  dynamic  graphical  behavior  of  these  ob¬ 
jects.  In  addition,  they  can  be  used  to  support  many 
of  the  services  that  these  tools  provide.  Finally, 
the  constraint  system  makes  it  easy  for  interactive 
design  tools  to  provide  constraints  to  the  interface 
designers.  For  example.  Lapidary  allows  users  to 
attach  constraints  to  objects  that  graphically  posi¬ 
tion  the  objects  or  control  their  dynamic  behavior. 
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The  support  provided  by  constraints  is  covered  in 
tfae  following  sections. 

S.2.1.1  Prototypes.  Interactive  design  tools  can 
use  pointer  variables  in  constraints  to  easily  con¬ 
vert  example  objects  to  prototypical  objects. 
Whenever  a  designer  attaches  a  constraint  to  an 
example  object,  the  design  tool  can  use  pointer 
variables  to  indirectly  reference  the  objects  to 
which  this  object  is  constrained.  Instances  of  this 
example  object  will  inherit  these  constraints,  and 
by  setting  the  pointer  variables  appropriately,  the 
instances  can  be  constrained  to  other  sets  of  ob¬ 
jects.  Thus,  pointer  variables  automate  part  of  the 
process  of  converting  the  example  object  to  a  pro¬ 
totype. 

However,  this  conversion  is  not  complete  until  the 
design  tool  has  identified  which  slots  in  the  exam¬ 
ple  should  be  parameters  that  are  set  at  instance- 
creation  time.  Part  of  this  identification  can  be  au¬ 
tomatically  performed  when  the  designer  saves  the 
object  The  design  tool  can  check  to  see  whether 
there  are  any  slots  in  the  saved  object  which  refer¬ 
ence  objects  that  are  not  being  saved.  If  so,  the 
design  tool  can  infer  that  these  slots  point  to  exam¬ 
ple  objects  and  replace  these  example  objects  with 
null  pointers.  This  process  converts  the  pointer 
variables  to  parameters,  because  instances  of  this 
prototype  can  instantiate  the  pointer  slots  with  the 
appropriate  objects  and  exhibit  the  same  behavior 
or  layout  relationship  that  the  prototype  did.  For 
example  in  Lapidary,  suppose  the  designer  has 
drawn  the  two  boxes  and  arrow  shown  on  the 
screen  in  Figure  8a.  The  designer  wants  arrows 
that  are  used  in  the  application  to  be  able  to  attach 
themselves  to  the  sides  of  objects,  so  the  designer 
attaches  the  ends  of  the  arrow  to  the  sides  of  the 
two  boxes  using  alignment  constraints  (Fig.  8  b). 
internally,  Lapidary  represents  the  constraints  us¬ 
ing  pointer  variables: 
arrow: 

endptl;  self. froro-obj. right-center 

endpt2:  self • to-obj . left-center 

from— Ob j;  boxl 

to— obj:  box2 

If  the  designer  then  saves  the  arrow  without  saving 
the  boxes.  Lapidary  notices  that  the  slots  from- 
obj  and  to— obj  do  not  point  to  objects  being 
saved,  infers  that  these  slots  point  to  example  ob¬ 
jects,  and  replaces  their  values  with  null  pointers. 
When  an  application  creates  an  instance  of  this 
arrow,  it  can  instantiate  the  from-obj  and  to— 


obj  slots  with  the  appropriate  objects  and  the  in¬ 
stance  arrow  will  attach  itself  to  the  desired  objects 
in  the  correct  way. 

Other  parameters,  such  as  the  label  of  a  labeled 
box  cannot  be  automatically  identified  without  as¬ 
sistance  from  the  designer.  However,  once  the  de¬ 
signer  identifies  these  slots,  the  design  tool  can  con¬ 
struct  a  constraint  that  retrieves  the  value  of  the 
slot  from  the  root  of  the  prototype.  This  constraint 
will  use  backpointers  in  the  aggregate  hierarchy 
to  climb  from  the  object  that  owns  the  slot  to  the 
top-level  object  in  the  prototype’s  aggregate  hierar¬ 
chy.  For  example,  suppose  the  color  of  the  mercury 
in  the  thermometer  in  Fig.  7  should  be  a  parameter. 
Once  the  designer  identifies  the  color  as  a  parame¬ 
ter.  the  design  tool  can  insert  the  following  con¬ 
straint  into  the  color  slot  for  the  bulb  and  mercury 
objects: 

color»a*lf . parent,  color 

This  constraint  goes  to  the  parent  of  either  the 
bulb  or  mercury  object,  which  is  the  thermometer, 
and  retrieves  the  color  set  by  the  programmer. 


5.2.1. 2  Spreadsheet  tools.  Spreadsheets  have 
proven  to  be  a  popular  design  interactive  design 
tool  (Wilde  and  Lewis  1990;  Myers  1991a).  One 
of  the  main  difficulties  in  constructing  a  spread¬ 
sheet  is  building  a  constraint  solver  for  the  spread¬ 
sheet’s  equations.  Garnet  automatically  provides 
such  a  constraint  solver  and  a  powerful  set  of  con¬ 
straints  that  will  be  adequate  for  most  spreadsheet 
interface-design  tools. 

Of  course,  C32  uses  the  built-in  constraint  solver 
to  evaluate  the  constraints  that  the  user  creates. 
In  addition,  C32  makes  extensive  use  of  constraints 
in  its  own  implementation.  For  example,  each 
value  display  has  a  constraint  that  ties  it  to  the 
actual  value  in  the  associated  object.  Therefore,  if 
the  value  changes  as  a  result  of  user  interaction 
with  the  interface,  the  cell’s  value  will  be  automati¬ 
cally  updated.  Similarly,  the  visibility  of  the  icons 
that  show  whether  the  slot  is  inherited  and  whether 
the  slot  contains  a  constraint  is  controlled  by  con¬ 
straints  to  the  actual  cells.  The  font  of  the  cell  label 
and  value  is  also  constrained  to  the  inheritance 
flag,  so  that  italics  is  used  if  the  slot  is  inherited. 

5.2.1. 3  Demonstration.  Constraints  help  support 
several  forms  of  demonstrational  programming 


106 


-58 


1  computer 


Fif.  7.  A  thennomeier  and  its  aggregate  hierarchy.  References 
from  one  object  to  another  use  paths  through  the  hierarchy. 
Objects  that  are  part  of  the  thermometer  have  programmer- 
assigned  names,  such  as  bulb  and  mercury,  and  references  to 
the  thermometer  from  a  pan  use  the  standard  parent  slot 

Fig.  Ba,  h.  The  designer  wants  to  create  a  prototype  arrow 
where  one  endpoint  should  be  connected  to  the  right  side  of  a 
box  and  the  other  endpoint  should  be  connected  to  the  left  side 
of  a  box.  To  do  this,  the  designer  draws  the  arrow  and  two 
boxts  a  and  uses  a  line-constraint  menu  to  attach  the  endpoints 
of  the  oiTow  to  the  example  boxts  b.  When  the  arrow  is  saved, 
the  references  to  the  boxes  in  the  arrow's  constraints  will  be 
replaced  with  null  pointers,  thus  convening  the  example  arrow 
to  a  prototype 

rif.9.  A  rsenu  that  displays  selections  by  moving  them  to  the 
'  tight  column.  A  designer  can  demonstrate  this  behavior  by  using 
constraints  to  place  an  unselected  item  in  the  left  column  and  a 
selected  item  in  the  right  column.  Lapidary  will  notice  that 
diflierent  constraints  control  the  position  of  a  selected  and 
unselected  item’s  left  side,  and  generate  code  to  select  the 
appropriate  constraint  based  on  the  item's  selection  status 
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(Myers  1990b).  In  demonstrational  programming, 
the  designer  manipulates  objects  under  the  obser¬ 
vation  of  the  design  tool.  The  design  tool  then  tries 
to  infer  the  general  form  of  the  behavior  from  this 
specific  example.  Peridot  (Myers  i99Qa)  and  Meta- 
Mouse  (Mauisby  and  Witten  1989)  are  two  other 
examples  of  demonstrational  systems. 

A  simple  form  of  demonstrational  programming 
is  one  in  which  a  designer  specifies  a  “before”  state 
for  an  object,  edits  it,  and  presents  the  design  toot 
with  an  “after”  state.  For  example,  a  “3-D”  button 
might  be  in  one  position  normally,  and  move  when 
the  mouse  is  pressed  on  it.  To  support  this,  the 
design  too!  would  allow  the  user  to  draw  the  two 
sutes.  It  would  then  figure  out  differences,  deter¬ 
mine  how  to  implement  the  changes,  and  generalize 
the  behavior  so  that  it  applies  to  any  of  a  related 
group  of  objects,  such  as  a  set  of  items  in  a  menu. 

If  the  designer  edits  the  objects  using  constraints, 
then  the  differences  are  fairly  easy  to  determine.  The 
design  tool  can  check  for  differences  in  constraints 
on  the  same  slots,  differences  in  offsets  or  scaling 
factors,  or  differences  in  pointer  variables.  Based 
on  these  differences,  the  design  tool  can  synthesize 
a  constraint  that  incorporates  the  before  and  after 
values  and  makes  the  selection  based  on  the  value 
of  an  indicator,  such  as  a  Boolean  variable. 

For  example.  Lapidary  supports  this  form  of  de¬ 
monstrational  programming  by  creating  a  copy  of 
the  object  to  be  demonstrated  and  allowing  the 
designer  to  edit  the  copy.  When  the  designer  is 
finished.  Lapidary  compares  slots  in  the  copy  (the 
“after”  state)  with  slots  in  the  original  (the  “before” 
state).  For  any  slots  that  are  different.  Lapidary 
creates  a  constraint  that  simply  chooses  between 
the  values,  based  on  a  controlling  parameter. 

For  instance,  suppose  a  designer  wanted  to  demon¬ 
strate  that  items  should  move  to  the  right  column 
of  the  menu  in  Fig.  9  when  the  user  clicks  on  them. 
This  behavior  could  be  demonstrated  by  selecting 
an  item  in  the  left  column  and  declaring  that  the 
item  is  in  its  “before"  state.  The  designer  could 
then  change  the  constraint  on  the  item’s  left  slot, 
so  that  the  item  is  now  positioned  in  the  right  col¬ 
umn.  The  before  and  after  states  would  look  as 
follows: 


Btfore 


After 


left:  self . objover. 

left 

objover;  left-column 


self. objover. 
right  - 
self. wxdth 
right-column 
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Because  the  “before”  and  “after”  values  of  the 
objover  and  left  slots  differ  in  this  example, 
Lapidary  synthesizes  constraints  that  choose  be¬ 
tween  the  differing  values,  based  on  the  value  of 
a  variable,  such  as  selected.  For  example,  the 
constraints  might  be: 

otajovsr;  if  self. selected 

then  right-column  else  left-column 
left:  if  self. selected 

then  self. objover. right  -  self,  width 
else  self. objover.  left 

Lapidary  then  creates  instances  of  these  new  con¬ 
straints  and  installs  them  in  the  other  items  in  the 
menu,  thus  generalizing  the  behavior  from  the  ex¬ 
ample  item  to  all  items  in  the  menu. 

The  constraints  in  Garnet  can  support  more  gener¬ 
al  forms  of  demonstrational  programming  as  well. 
To  guess  which  kinds  of  layouts  the  user  is  trying 
to  achieve,  as  in  Peridot  (Myers  1990a),  the  creator 
of  a  design  tool  can  derive  the  set  of  constraints 
that  enforce  the  desired  types  of  layouts.  These  con¬ 
straints  will  comprise  a  formal,  rigorous  basis  for 
the  demonstrational  system.  When  a  user  manipu¬ 
lates  objects,  the  design  tool  can  use  various  met¬ 
rics  to  measure  how  well  the  various  constraints 
fit  the  demonstrated  behavior  and  choose  those 
constraints  that  best  fit  the  behavior.  The  advan¬ 
tage  of  using  constraints  is  that  quantitative  met¬ 
rics  can  be  developed  that  rigorously  assess  the 
closeness  with  which  various  constraints  match  a 
demonstrated  behavior.  Because  the  demonstra- 
tional  system  can  explain  its  inferences  in  terms 
of  the  metric,  the  designer  of  the  demonstrational 
system  can  improve  the  system’s  inferences  by 
modifying  the  metrics,  based  on  feedback  received 
from  users. 

5. 2. 1.4  Annotation  of  specifications.  Some  sys¬ 
tems,  such  as  Jade  and  Chisel  (Singh  and  Green 
1989),  produce  a  rough  cut  of  an  interface  from 
a  textual  specification.  An  interactive  design  tool 
can  then  be  used  to  polish  the  generated  interface, 
for  example,  by  adding  decorations  or  reposition¬ 
ing  objects.  If  the  interface  designer  later  changes 
the  textual  specification,  the  changes  made  by  the 
design  tool  should  be  remembered.  Thus,  the  de¬ 
sign  tool  should  annotate  the  textual  specification 
in  some  fashion. 

In  a  Garnet-generated  design  tool,  constraints  arc 
used  when  adding  decorations  or  repositioning  ob¬ 
jects.  For  example,  if  a  rectangle  is  drawn  that  en- 
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closes  a  group  of  radio  buttons,  it  will  typically 
be  attached  to  the  radio  button  group  using  con¬ 
straints.  In  turn,  the  radio  buttons  are  tied  to  var¬ 
ious  entities  in  the  textual  specification.  By  keeping 
track  of  the  objects  to  which  constraints  are  ap¬ 
plied,  the  tool  can  determine  to  which  entities  in 
the  textual  speciilcation  the  decorations  apply. 
Thus,  even  if  a  designer  changes  the  underlying 
textual  specification,  the  interactive  design  tool  can 
still  remember  the  graphical  changes  that  were 
made  and  faithfully  reproduce  them  when  the  tex¬ 
tual  specification  is  run  through  the  interface  gen¬ 
erator.  For  example,  the  rectangle  in  the  above  ex¬ 
ample  would  be  constrained  to  surround  the  set 
of  radio  buttons,  so  the  rectangle  will  grow  au¬ 
tomatically  if  new  items  are  added  to  the  set. 

Jade  takes  advantage  of  Garnet’s  annotation  capa¬ 
bilities  when  a  graphics  artist  uses  a  direct  manipu¬ 
lation  editor  to  either  change  the  layout  or  add 
decorations  to  a  Jade-created  dialog  box.  To  anno¬ 
tate  the  textual  specification.  Jade  keeps  track  of 
which  objects  are  being  repositioned  or  decorated 
and  then  maps  these  objects  to  their  underlying 
entities  in  the  textual  specification.  When  the 
graphics  artist  is  satisfied  and  saves  the  dialog  box. 
Jade  uses  Garnet’s  writing  facility  to  save  the  de¬ 
corations,  constraints  used  to  reposition  the  ob¬ 
jects,  and  references  to  the  appropriate  items  in 
the  textual  specification. 

5.2.1  5  Rule-based  systems.  Many  systems  that 
generate  interfaces  from  textual  specifications  use 
rules  in  order  to  layout  the  various  scenes  in  the 
interface  (Vander  Zanden  and  Myers  1990;  Wiccha 
et  al.  1989;  Bennett  et  al.  1989).  One  way  to  imple¬ 
ment  the  rules  is  to  have  them  generate  a  set  of 
constraints  from  a  prototypical  set  of  constraints. 
The  use  of  pointer  variables  makes  it  easier  for 
rules  to  create  instances  of  these  constraints,  be¬ 
cause  the  pointer  variables  can  be  made  to  point 
to  the  object  or  set  of  objects  to  which  a  rule  is 
applied  and  the  constraints  will  automatically  en¬ 
force  the  rule.  For  example,  a  rule  that  places  a 
set  of  buttons  at  the  top  right  of  another  group 
of  buttons  might  be  expressed  as: 

at-iop-rxght-rule: 

loft:  seif. buttons. right»10 
top;  self. buttons. top 

A  tool  could  apply  this  rule  by  generating  instances 
of  these  constraints  in  the  appropriate  slots  in  a 
button  group  and  setting  the  buttons  pointer. 
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uses  rules  similar  to  this  one  in  laying  out  objects 
in  a  dialog  box. 

5.3  Automatic  graphical  update 

The  graphical  object  system  in  Garnet  is  different 
from  many  other  systems  in  two  respects.  First, 
it  uses  a  retained  object  model  that  allows  it  to 
automatically  update  the  screen  when  objects 
change  or  a  part  of  the  window  becomes  uncov¬ 
ered.  Most  other  toolkits  force  the  application  to 
manually  handle  redisplay  by  determining  which 
objects  are  changed  and  which  objects  they  overlap 
and  then  issuing  erase  and  draw  commands  that 
cause  the  display  to  be  appropriately  updated.  A 
second  difference  from  other  systems  is  that  the 
display  system  is  integrated  with  the  constraint  sys¬ 
tem,  so  the  constraint  system  automatically  notifies 
the  display  system  whenever  an  object  changes. 

The  retained  object  model  is  somewhat  similar  to 
a  display  list  in  that  each  graphical  object  on  the 
screen  corresponds  to  an  object  in  memory.  How¬ 
ever,  the  objects  are  at  a  higher  level  than  the  ob¬ 
jects  in  a  display  list,  because  they  are  integrated 
with  the  constraint  system,  can  be  accessed  by  an 
application,  and  are  used  by  Garnet  to  determine 
which  portions  of  the  display  to  update.  For  exam¬ 
ple,  to  move  a  rectangle  to  a  new  position,  the 
application  sets  the  left  and  top  slots  of  the 
object  and  Garnet  automatically  takes  care  of  eras¬ 
ing  the  object  at  its  old  position  and  drawing  it 
at  the  new  position.  In  addition,  the  constraint  sys¬ 
tem  propagates  the  changes  to  other  objects  in  the 
system,  and  these  objects,  as  well  as  any  other  ob¬ 
jects  that  overlap  the  changed  objects,  are  also  re¬ 
drawn.  If  the  window  manager  needs  part  of  the 
window  to  be  redrawn  (for  example,  because  the 
user  has  uncovered  it).  Garnet  can  handle  this  au¬ 
tomatically  without  involving  the  application. 

The  algorithm  used  by  Garnet  always  tries  to  mini¬ 
mize  the  number  of  objects  that  are  erased  and 
redrawn,  rather  than  simply  redrawing  the  entire 
window,  which  can  be  important  for  complex 
scenes.  Garnet  keeps  track  of  ail  objects  changed 
by  either  the  application  or  the  constraint  system. 
When  asked  to  update  the  screen,  it  finds  the 
bounding  rectangles  of  the  changed  objects  in  their 
old  and  new  positions  and  then  redraws  all  objects 
that  intersect  those  regions.  Clipping  regions, 
which  are  supported  by  the  underlying  window 
managers,  are  used  so  that  other  objects  will  not 
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be  affected.  As  an  example  of  the  resulting  per.or- 
mance,  moving  one  object  through  a  window  con¬ 
taining  200  other  objects  takes  14.9  milliseconds 
per  move  on  a  Sun  SPARCStation  (67  moves  per 
second)  rather  than  the  188  milliseconds  (5.32 
moves  per  second)  it  would  take  if  Garnet  simply 
redrew  all  the  objects  in  the  window  each  time. 

The  advantage  of  the  retained  object  model  for 
tool  builders  is  that  they  do  not  have  to  have  to 
build  the  elaborate  data  structures  required  to  re¬ 
fresh  the  screen  and  they  do  not  have  to  handle 
the  complex  task  of  interfacing  the  constraint 
solver  with  the  display  manager.  When  a  property 
of  an  object  should  change  (e.g.,  to  have  a  new 
color  or  position),  the  tool  can  simply  set  the  ap¬ 
propriate  slot  of  the  object.  If  other  objects  are 
affected  by  the  change,  their  slots  will  be  automati¬ 
cally  changed  as  well.  If  an  object  should  be  de¬ 
leted,  it  can  simply  be  removed  from  the  window’s 
list  of  objects.  Garnet  handles  the  rest. 

Another  advantage  is  that  often  tools  do  not  need 
to  create  their  own  representation  of  the  data.  Each 
window  contains  a  list  of  the  objects  in  it  and  appli¬ 
cations  are  free  to  add  their  own  slots  to  objects 
to  hold  any  necessary  extra  information  (as  de¬ 
scribed  above  in  Sect.  5. 1.3.3).  Therefore,  the  win¬ 
dow’s  object  list  can  often  be  used  by  applications 
as  their  description  of  the  current  state.  All  the 
application-specific  slots  will  be  written  out  au¬ 
tomatically  to  the  file  along  with  the  standard 
graphical  slots. 


5.4  Behaviors 

In  Garnet,  the  graphical  objects  do  not  respond 
to  input  events.  Instead,  separate  objects,  called 
interactor  objects,  handle  all  input  (Myers  1989b; 
Myers  1990c).  The  interactors  encapsulate  the 
common  interactive  behaviors  found  in  direct  ma¬ 
nipulation  interfaces.  Each  type  of  interactor  han¬ 
dles  a  different  kind  of  behavior.  Currently,  the 
interactor  types  are: 

Menu-  to  choose  one  or  more  items  from 

Interactor:  a  Set  or  fot  a  single,  stand-alone 

button.  This  interactor  can  be 
used  for  menus,  radio  buttons, 
and  making  selection  “handles” 
appear  over  objects  in  a  graphics 
editor. 


uove-croa^  to  move  Or  change  the  size  of  an 
Interactor:  object  OT  onc  of  a  Set  of  objects 

using  the  mouse.  This  interactor 
can  be  used  for  one-dimensional 
or  two-dimensional  scroll  bars, 
horizontal  and  vertical  gauges, 
and  for  moving  or  growing  appli¬ 
cation  objects  in  a  graphics  edi¬ 
tor. 

Hew-Point-  to  enter  one,  two,  or  an  arbitrary 
Interactor:  number  of  new  points  using  the 

mouse,  for  example  for  creating 
new  lines  or  rectangles  in  an  edi¬ 
tor. 

Angle-  to  calculate  the  angle  that  the 

Interactor:  mouse  moves  around  some  point. 

This  can  be  used  for  circular 
gauges  or  for  rotating  objects. 
Trace-  to  get  all  of  the  points  the  mouse 

interaetor:  goes  through  between  Start  and 

end  events,  as  is  needed  for  free¬ 
hand  drawing. 

Text-string-  to  input  a  small  (optionally  multi- 
Interactor:  line)  String  of  text. 

Each  interactor  is  parameterized  in  various  ways, 
so  the  programmer  can  control  the  mouse  or  key¬ 
board  events  that  cause  it  to  start  and  stop  as  well 
as  the  optional  application  procedures  to  be  called 
on  completion.  The  most  significant  parameters, 
however,  are  the  objects  that  are  used  as  the  places 
where  the  interactor  should  operate  and  the  (op¬ 
tional)  objects  that  will  handle  feedback.  For  exam¬ 
ple,  the  programmer  might  create  a  set  of  text  ob¬ 
jects  to  be  the  domain  of  selection  in  a  menu  and 
a  black  XOR  rectangle  to  be  the  feedback.  Each 
type  of  interactor  has  a  well-defined  protocol  with 
which  it  controls  the  graphics.  This  protocol  is  ex¬ 
plained  in  depth  in  (Myers  1990c). 

The  interactors  arc  first-class  objects,  and  they  can 
be  included  in  prototypes  (e.g.,  a  prototype  scroll 
bar).  Interactors  in  prototypes  also  will  be  saved 
to  disk  and  read  back  in  automatically. 

Another  feature  of  interactors  is  that  they  can  be 
easily  turned  on  and  off.  Each  interactor  has  an 
active  slot,  which  can  contain  a  constraint  that 
determines  whether  the  interactor  should  run  or 
not.  This  makes  it  easy  for  design  tools  to  imple¬ 
ment  the  “Build”  vs  “Run”  modes:  when  in  build- 
mode,  the  interactors  in  the  interface  under  con¬ 
struction  are  inactive,  and  when  in  run-mode,  they 
are  active.  Similarly,  the  interactors  that  handle 
selection  and  editing  for  the  design  tool  use  the 
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reverse  constraint.  Gilt  and  Lapidary  use  this  fea¬ 
ture  to  disable  widgets  unless  the  user  hits  the 
“Run”  button. 

5.4.1  Advantages  of  interactors  for  writing 
graphical  programs 

The  interactors  paradigm  helps  programmers 
create  graphical  programs  in  a  number  of  ways, 
hirst,  by  separating  out  the  graphics  from  the  be¬ 
havior,  the  code  of  the  tool  itself  is  more  modular. 
Second,  it  makes  it  easier  to  investigate  different 
looks  and  feels.  Third,  because  each  interactor  pro¬ 
vides  a  high-level  of  built-in  functionality,  many 
otherwise  complex  behaviors  can  be  added  to  inter¬ 
faces  easily.  For  example,  a  common  way  to  handle 
selection  is  for  the  user  to  press  on  an  object  and 
have  “handles”  appear  (see  Fig.  10).  When  the  user 
presses  on  a  handle,  the  object  underneath  moves 
or  changes  size.  This  behavior  can  be  provided  in 
Garnet  by  using  a  menu-intcractor  with  the  han¬ 
dles  as  a  feedback  object  for  the  selection  and  a 
move-grow-interactor  with  the  handles  as  the  start¬ 
ing  position.  The  programmer  only  needs  to  create 
instances  of  these  two  types  of  interactors  and  pro¬ 
vide  the  appropriate  parameters;  no  event  loops 
need  to  be  coded  and  no  methods  need  to  be 
written.^  Also,  in-place  text  editing  is  very  easy 
to  support,  simply  by  attaching  a  text-editing  inter- 
actor  to  any  text  string  in  the  interface.  For  exam¬ 
ple,  it  was  easy  in  the  Gilt  interface  builder  to  sup¬ 
port  editing  of  the  menu  and  button  labels  directly 
in  the  graphics  window  using  a  text-interactor 
(rather  than  requiring  the  new  labels  to  be  entered 
in  a  property  sheet).  The  sizes  of  the  graphics  sur¬ 
rounding  the  label  are  automatically  adjusted  as 
letters  are  typed,  due  to  the  constraints  built  into 
the  widgets  (for  example,  the  rectangles  around  a 
labeled-button  will  expand  and  shrink). 

Fourth,  the  interactors  package  supports  dragging 
objects  among  windows  in  the  same  way  that  they 
are  moved  inside  a  single  window.  This  can  be  used 
to  move  or  copy  objects  from  one  window  to  an¬ 
other  rather  than  using  the  more  clumsy  cut-and- 
paste  style. 

Fifth,  the  interactors  package  supports  the  win- 
ilow  iiiaiiugci  cut  liiilici  tu  allow  easy  eupyiiig  ol 

text  from  one  application  to  another.  Extensions 
to  support  copying  of  graphics  are  planned. 

*  However,  see  Sect.  5.6,  where  a  widget  that  handles  this  au¬ 
tomatically  IS  explained 
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5.4.2  Advantages  of  interactors  for  IDTs 

In  addition  to  the  general  advantages  of  interac¬ 
tors,  there  is  a  particular  advantage  for  the  designer 
of  an  interactive  design  tool.  If  the  tool  wants  to 
allow  the  user  to  deHne  the  interactive  behaviors 
of  the  objects  being  designed,  it  must  first  have 
a  model  of  those  behaviors.  In  many  systems,  this 
model  consists  of  a  set  of  pre-defined  interaction 
techniques  that  are  tightly  bundled  with  the  graph¬ 
ics,  making  it  diflicult,  if  not  impossible,  to  attach 
behaviors  to  application  objects.  In  contrast,  the 
interactors  model  separates  behavior  from  the 
graphics,  so  that  behaviors  may  be  attached  to  wid¬ 
get  objects  (e.g.,  menus,  scroll  bars,  buttons)  as  well 
as  application  objects.  Indeed,  several  of  the  inter- 
actors,  such  as  the  move-grow,  new-point,  and 
trace  interactors,  were  specifically  designed  for  ap¬ 
plication  objects,  while  the  menu,  text-string,  and 
angle  interactors  all  have  application  uses  (the 
menu.interactor,  for  example,  can  be  used  to  select 
one  or  more  application  objects). 

The  interactors  model  also  provides  a  rich  set  of 
parameters  that  allow  designers  to  specify  a  wide 
variety  of  behaviors  without  having  to  drop  down 
to  the  programming-language  level.  Because  there 
are  only  six  types  of  interactors  and  the  parameters 
are  well-defined,  an  interctive  design  tool  can  easily 
provide  dialog  boxes  for  the  user  to  fill  in  the  de¬ 
sired  values  or  can  attempt  to  infer  the  behavior 
and  its  parameters  from  the  user’s  actions.  Thus, 
the  interactors  make  it  much  easier  to  implement 
interactive  design  tools  that  allow  a  designer  to 
specify  the  behavior  of  application  objects  as  well 
as  the  behavior  of  new  widget  objects. 

Lapidary  is  a  good  example  of  a  design  tool  that 
takes  advantage  of  these  features  of  interactors.  It 
provides  dialog  boxes  for  each  of  the  interactors 
and  allows  the  user  to  attach  graphics  to  an  inter¬ 
actor  by  selecting  graphical  objects  and  pointing 
to  the  a  ipropriate  graphical  parameter  in  the  dia¬ 
log  box  (e.g.,  the  start-where  parameter,  which 
controls  which  objects  the  intcractor  operates  on, 
or  the  interim  and  final  feedback  parameters,  which 
control  what  type  of  feedback  the  user  sees  as  the 
behavior  is  executing).  For  example,  if  the  user  is 
(TC.'iliuH.  ucw  kiiul  of  iiifiiii.  lu;  riiii  |miII  up  ili<- 
choicc-of-itciiis  dialog  box  (see  Fig.  J),  create  an 
instance  of  a  menu  interactor,  and  attach  it  to  the 
graphics  that  the  user  has  created.  The  behavior 
can  then  be  interactively  tested  by  putting  Lapid¬ 
ary  in  “test”  mode. 
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Fig.  10.  Standard  built-in  Garnet  graphics-seicction 
gadget.  It  display!)  control  handles  around  the  selected 
object  or  objects.  Pressing  on  a  object  with  the  left 
button  selects  It.  If  the  user  presses  with  shift-left  or  the 
middle  mouse  button,  then  other  objects  can  be  added  or 
removed  from  the  selection  set.  Pressing  on  a  white 
handle  moves  the  object,  and  pressing  on  a  black  one 
changes  the  object’s  size.  When  a  line  is  selected,  only 
three  control  points  are  shown:  the  black  ones  change 
the  end  paint  and  the  white  one  moves  the  line,  keeping 
the  same  length  and  slope,  if  multiple  objects  arc  selected, 
then  they  all  move  or  change  size  together 

Fig.  lla,  h.  The  property  sheet  a  that  appears  for  a  radio 
button  panel  b  in  Gilt.  The  aggrelist  control  slots,  such  as 
DIRECTION  and  v-spacinc  can  be  changed  dynamically  and 
the  radio  buttons  will  re-orient  automatically 


Lapidary  exploits  interactors  in  other  ways  as  well. 
Internally,  interactors  make  it  much  easier  to 
create  all  of  Lapidary’s  complicated  behaviors, 
such  as  the  multiple  ways  of  selecting  objects  and 
providing  feedback  or  the  diflerent  ways  of  select¬ 
ing  constraints  in  the  iconic  constraint  menus.  Ex¬ 
ternally,  Lapidary  uses  the  interactors  to  separate 
the  editing  of  graphics  and  behaviors.  Users  creat¬ 
ing  objects  from  scratch  can  concentrate  on  defin¬ 
ing  their  graphics  and  behaviors  separately  and  in¬ 
tegrating  them  when  they  are  finished.  Further¬ 
more,  they  can  later  edit  either  the  behaviors  or 
graphics,  thus  modifying  either  the  look  or  the  feel 
without  touching  the  other.  Instances  of  widgets 
from  prototype  libraries  can  be  similarly  edited. 
This  separation  allows  a  user  to  rapidly  prototype 
difierent  looks-and-feels. 

Currently,  we  are  investigating  ways  to  infer  the 
parameters  of  the  interactors  from  a  demonstration 
of  the  behavior,  as  in  the  earlier  Peridot  system 
(Myers  1988).  Because  there  are  only  six  possible 
behaviors  and  a  small  number  of  parameters,  the 


inferences  about  the  meaning  of  the  user’s  demon¬ 
stration  have  a  good  chance  of  being  correct 

5.5  Automatic  layout 

There  are  many  times  when  elements  of  a  user  in¬ 
terface  need  to  be  displayed  in  a  regular  fashion. 
For  example,  the  items  in  a  menu  are  often  evenly 
spaced  in  a  column.  Garnet  provides  various  spe¬ 
cial  forms  of  aggregates  that  automatically  lay  out 
their  components.  Interactive  design  tools  can  easi¬ 
ly  provide  automatic  layout  to  users  by  simply 
creating  instances  of  these  special  aggregates  and 
allowing  users  to  then  add  the  components. 

One  such  aggregate,  called  an  “aggrelist,"  will  ar¬ 
range  the  elements  in  a  row,  column,  or  table.  The 
programmer  can  specify  the  spacing  of  the  elements 
and  whether  they  are  centered  or  justified  to  the 
left,  right  top,  or  bottom.  Each  element  can  be  indi¬ 
vidually  created  by  a  program  and  added  to  the 
aggregate.  Alternatively,  a  single  prototype  can  be 


112 


-64 


supplied  along  with  a  list  of  strings  or  other  values 
and  the  aggregate  will  automatically  create  an  in¬ 
stance  of  the  prototype  for  each  string  or  value. 
Aggrelists  are  used  throughout  the  Garnet  widget 
set  to  control  the  layout  of  menus  and  buttons. 
Because  the  layout  parameters  to  an  aggrelist  can 
be  changed  dynamically  (e.g.,  to  change  the  ele¬ 
ments  to  be  centered  or  left-justiiied  or  to  put  them 
ih  multiple  rows  or  columns),  this  allows  the  toolkit 
user  to  customize  the  layout  of  the  elements.  For 
example,  the  Gilt  interface  builder  only  needs  to 
set  the  value  of  the  orientation  field  of  an  aggrelist 
to  change  a  set  of  radio  buttons  from  horizontal 
to  vertical.  No  special  code  is  needed  in  Gilt  to 
adjust  the  layout.  The  controlling  slots  are  pro¬ 
vided  to  the  user  as  fields  in  a  property  sheet  (see 
Fig.  11).  Aggrelists  are  also  helpful  in  the  C32  im¬ 
plementation,  where  they  are  used  to  lay  out  the 
fields  in  columns. 

Another  special  type  of  aggregate  will  arrange  the 
elements  in  a  tree  or  graph.  A  default  layout  algo¬ 
rithm  is  supplied,  but  the  programmer  can  supply 
a  different  one  if  desired.  There  are  also  default 
prototypes  for  graphics  for  the  nodes  and  arcs,  but 
again  the  programmer  can  supply  different  proto¬ 
types. 


5.6  Widgets 

The  Garnet  widget  set  contains  many  widgets  that 
help  create  interactive  programs,  such  as  visual  in¬ 
teractive  design  tools.  It  contains  the  standard  wid¬ 
gets  found  in  other  toolkits,  such  as  radio  buttons, 
check  boxes,  scroll  bars,  sliders,  text-entry  fields, 
and  various  forms  of  fixed,  pop-up,  and  pull-down 
menus.  These  come  in  two  varieties:  the  Garnet 
look-and-feel  shown  in  Fig.  1  and  a  Motif  look- 
and-feel  (Fig.  12).  These  can  be  used  to  make  the 
dialog  boxes  and  main  command  menus  of  an  edi¬ 
tor.  There  are  also  widgets  to  pop-up  windows  with 
error  messages,  confirmation  requests,  and 
prompts.  It  is  interesting  to  note  that  implementing 
the  Motif  widget  set  (which  does  not  use  any  of 
the  Motif  code  that  implements  the  Xtk  C  version) 
took  only  two  man- weeks  on  top  of  the  Garnet 
toolkit  intrinsics. 

In  addition,  however,  the  Garnet  widget  set  also 
contains  many  high-level  widgets  that  can  help 
with  the  insides  of  the  design  tool  or  end-applica¬ 
tion  windows.  For  example,  one  gadget  supplies 


a  scrolling  window  facility  that  displays  horizontal 
and  vertical  scroll  bars  and  automatically  handles 
refreshing  parts  that  are  scrolled  onto  the  screen. 
Another  special  Garnet  widget  supports  selection 
of  graphical  objects.  If  the  programmer  creates  an 
instance  of  a  multiple— selection  object  in 
a  window,  then  any  of  the.  objects  in  the  window 
can  be  selected  using  the  mouse  and  selection  han¬ 
dles  will  appear  around  them  (see  Fig.  10).  The  ob¬ 
jects  then  can  be  moved  or  changed  in  size.  All 
this  functionality  is  supplied  by  the  multiple- 
selection  widget,  and  the  programmer  only  has 
to  make  sure  that  the  objects  to  be  edited  under¬ 
stand  the  standard  protocol  so  they  can  be  modi¬ 
fied.  This  widget  is  used  extensively  by  Gilt. 
Another  useful  widget  for  some  design  tools  is  a 
property  sheet,  which  shows  labels  and  current 
values  (see  Fig.  II).  Each  label  is  usually  the  slot 
name  of  the  field  of  the  object  that  specifies  the 
property  and  the  value  is  usually  a  textual  repre¬ 
sentation  of  the  value.  However,  the  property-sheet 
widget  allows  an  arbitrary  widget  to  be  used  as 
the  value.  For  example,  in  Fig.  11,  a  special  widget 
is  used  for  the  direction  slot,  which  allows  the 
user  to  select  one  of  a  set  of  values  with  the  mouse, 
and  the  font  property  contains  an  icon,  which 
pops  up  a  font-selection  dialog  box  (which  itself 
was  created  using  Gilt). 

An  interesting  feature  of  the  Garnet  system  is  that 
the  built-in  widgets  can  be  easily  used  in  interactive 
design  tools  even  though  they  were  hand-coded* 
without  any  thought  for  their  use  in  this  way.  The 
ability  to  dynamically  load  Garnet  objects  and 
dynamically  change  their  properties  makes  any 
Garnet  object  usable  in  design  tools.  For  example, 
the  widgets  displayed  by  Gilt  are  simply  those  that 
were  already  in  the  Garnet  widget  set.  We  did  not 
have  to  create  new  widgets  for  use  by  Gilt. 

Lapidary  takes  advantage  of  Garnet’s  button  and 
type-in  widgets  in  constructing  its  interactor  dialog 
boxes,  main  editor  menu,  and  iconic  constraint 
menus.  It  also  extensively  uses  the  error  gadgets 
to  inform  users  of  various  mistakes.  In  the  future, 
we  plan  to  integrate  the  property-sheet  widgets 
into  Lapidary  in  order  to  allow  the  user  to  edit 
non-graphical  properties  of  an  object.  Lapidary 
does  not  use  the  multiple-selection  widget, 
because  it  implements  a  more  complex  selection 
model.  For  example,  by  using  different  keyboard 
keys  and  mouse  buttons,  the  user  can  select  the 
aggr*8***  of  tb*  selected  object  or  select  the  object 
hidden  underneath  the  object. 
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Fig,  12.  Some  of  the  widgets  with  a  Motif 
look-and-feel  implemented  in  Garnet 


Finally,  the  C32  window  uses  scroll  bars  and  the 
scrolling-window  widget.  Of  course,  the  menus  and 
buttons  are  Garnet  widgets.  The  value  of  each  slot 
uses  a  scrollable-text  Held  widget  (so  if  the  value 
is  too  large,  it  can  be  scrolled  left  and  right). 

5.7  Other  toolkit  features 

In  addition  to  those  discussed  above,  the  Garnet 
system  also  provides  a  few  other  features  that  make 
it  easier  to  build  interactive  design  tools. 

First,  the  object-oriented  graphics  package  and  the 
interactor  objects  hide  the  details  of  the  window 
manager  from  application  programs.  Therefore,  a 
programmer  can  create  a  tool  that  will  run  on  dif¬ 
ferent  architectures.  In  addition,  the  interfaces 
created  by  the  users  of  the  interactive  design  tools 
will  also  run  on  multiple  architectures. 

Another  feature  stems  from  the  decision  to  imple¬ 
ment  Garnet  in  Lisp.  The  built-in  Lisp  interpreter 
is  available  to  the  tool  builder  so  that  no  additional 
interpreters  are  needed.  This  helps  support  the  in¬ 
teractive  loading  of  objects  and  interactive  creation 
of  constraints,  as  described  above.  In  addition,  the 


interpreter  can  be  used  to  support  "Run  Mode,” 
where  the  tool  allows  the  interface  to  be  exercised 
to  show  how  it  will  operate  for  the  end  user.  The 
tool  can  simply  create  the  actual  objects,  con¬ 
straints,  and  interactors  that  will  be  present  in  the 
end-user  interface  and  the  Lisp  interpreter  allows 
the  interactors  and  constraints  to  operate. 

6  Future  work 

The  Garnet  project  is  on-going  and  we  are  con¬ 
stantly  trying  to  improve  the  toolkit  and  high-level 
tools.  Current  work  on  the  toolkit  is  focusing  on 
increasing  the  functionality  and  efficiency  of  the 
object  system  and  the  constraints.  We  will  also  add 
gesture  recognition  as  a  new  primitive  interactor 
type,  so  that  applications  and  interactive  design 
tools  can  experiment  with  gestural  interfaces. 

Most  future  work,  however,  will  concentrate  on 
the  interactive  design  tools  themselves.  The  tools 
described  here  need  to  be  completed  and  released 
and  more  functionality  needs  to  be  added.  In  addi¬ 
tion.  we  plan  to  explore  new  forms  of  tools  that 
will  allow  even  more  of  the  application-specific  be- 
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havior  of  objects  to  be  specified.  The  emphasis  will 
be  on  specifying  the  behavior  by  demonstration 
rather  than  through  dialog  boxes  or  hand-cod¬ 
ing. 

In  addition  to  new  specific  tools,  we  want  to  look 
at  more  comprehensive  “frameworks”  for  interac¬ 
tive  design  tools  and  other  interactive  applications. 
For  example,  almost  all  applications  have  a  palette 
o/  choices  and  a  workspace  window  in  which  the 
user  creates  instances  of  objects  in  the  palette.  Ob¬ 
jects  in  the  workspace  window  can  then  be  selected 
and  processed  further.  Whereas  the  toolkit  pro¬ 
vides  primitives  that  make  all  these  steps  easy,  t.ie 
programmer  still  has  to  put  them  together.  A 
framework  like  Unidraw  (Vlissides  and  Linton 
1989)  or  MacApp  (Schraucker  1986)  would  make 
this  easier.  Thus,  we  will  be  developing  cue  for 
Garnet.  The  planned  framework  will  also  support 
Undo,  Help,  and  other  high-level  operations. 
Another  focus  will  be  on  how  to  provide  toolkit- 
level  support  for  demonstrational  interfaces  to 
make  it  easier  for  design  tools  and  applications 
to  implement  a  demonstrational  interface. 

7  Conclusions 

By  specifically  designing  the  underlying  toolkit  in- 
trinsics  to  support  the  insides  of  application  win¬ 
dows,  Garnet  is  able  to  make  the  creation  of  visual 
interactive  design  tools  significantly  easier  than 
with  conventional  toolkits.  Features  such  as  the 
use  of  a  prototype-instance  object  system,  con¬ 
straints,  automatic  graphical  update,  automatic 
object  saving,  automatic  layout,  the  use  of  interac¬ 
tor  objects,  and  high-level  widgets  that  support 
graphical  selection,  property  sheets,  and  error  re¬ 
porting  have  allowed  us  to  quickly  create  a  variety 
of  innovative  interactive  design  tools.  In  addition, 
these  tools  are  able  to  help  build  the  application- 
specific,  highiy-interactive  graphical  parts  of  user 
interface  and  not  just  layout  the  widgets  that  go 
around  the  main  application  window  or  in  dialog 
boxes. 
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Garnet  is  a  comprehensive  user  interface  development  environment  in  Lisp  for 
X/11  (Display  Postscript  and  Macintosh  versions  are  in  progress).  It  helps 
create  graphical,  highly-interacdve.  direct  manipulation  user  interfaces.  Garnet 
contains  many  high-level  tools,  including  the  Gilt  interface  builder  [Myers  9 Id], 
the  Lapidary  interactive  design  tool  [Myers  89b],  the  C32  spreadsheet  system 
[Myers  91a],  the  Jade  dialog  box  system  [Vander  Zanden  90],  and  mrae  to  come. 
Garnet  also  contains  a  complete  toolkit,  which  uses  constraints  [Vander  Zanden 
91a],  a  prototype-instance  object  model,  and  a  new  mode!  for  handling  input 
[Myers  90c].  The  toolkit  also  contains  two  complete  widget  sets,  one  with  the 
Modf  look  and  feel. 

Typical  applications  created  with  Garnet  include:  drawing  programs  similar  to 
Macintosh  MacDraw,  user  interfaces  for  expert  systems  and  ocher  AI  applica¬ 
tions,  box  and  arrow  diagram  editors,  graphical  programming  languages,  game 
user  interfaces,  simulation  and  process  monitoring  programs,  user  interface  con¬ 
struction  tools.  CAD/CAM  programs,  etc.  Garnet  is  in  the  public  domain  and 
is  freely  available.  As  of  fall,  1992,  over  30  projects  around  the  world  are  using 
the  system  regularly.  You  can  get  Garnet  by  anonymous  FTP  from 
a . gp.cs  .cmu.edu.  Change  to  the  directory  / us r /garnet /garnet/ 


and  retrieve  the  readme  Gle  for  instructions.  Or  you  can  send  electronic  mail 
to  garnet 6cs .  emu .  edu.  Garnet  stands  for  fi.enerating  an  A<nalgam  of 
Eeaitiine,  ^Jovel  fidittss  and  loolldts. 

One  of  the  important  goals  of  the  Garnet  project  is  to  allow  all  zspeexs  of  the 
user  interface  to  be  created  without  conventional  programming.  In  particular,  we 
want  to  allow  the  user  to  draw  example  piemres  to  show  what  the  user  interface 
will  lode  like,  and  then  demonstrate  how  the  user  interface  will  respond  to  in¬ 
puts  from  the  end  user.  As  a  result,  demonstrational  techniques  are  widely  used 
in  Garnet,  mainly  in  the  various  higher-level  tools.  This  chapter  discusses  some 
of  these.  Other  papers  about  Garnet  discuss  jie  overall  design  [Myers  90d],  the 
components,  the  programming  style  [Myers  92a]  [Myers  92f],  and  there  is  a 
complete  reference  manual  [Myers  92b]. 

K  The  Lapidary  user  interface  tool  allows  the  pictorial  aspects  of  programs  to  be 
specified  graphically  [Myws  89bl  [Vander  Zanden  9lb].  A  “Lapidary”  is  a 
worlonan  who  cuts,  polishes  and  engraves  precious  stones,  and  here  is  a  Lisp- 
Based  Assistam  for  £no(otyping  Interface  Qesigns  Rowing  Remarkable  ^ield. 
In  addition,  the  behavior  of  these  objects  at  run-time  can  be  specified  using 
dialogue  boxes  and  by  demonstration.  In  particular.  Lapidary  allows  the  designer 
to  draw  pictures  of  application-specific  graphical  objects  which  will  be  created 
and  maintained  at  run-time  by  the  application.  This  includes  the  graphical 
entities  that  the  end  user  will  manipulate  (such  as. the  components  of  the 
picture),  the  feedback  that  shows  which  objects  are  selected  (such  as  small  boxes 
around  an  object),  and  the  dynamic  feedback  objects  (such  as  hair-line  boxes  to 
show  where  an  object  is  being  dragged).  Lapidary  is  a  direct  descendent  of 
Peridot  (chapter  6)  and  extends  a  number  of  Peridot’s  ideas. 


(C) 

In  addition,  like  Peridot,  Lapidary  supports  the  construction  and  use  of  “widgets” 
(sometimes  called  interaction  techniques  or  gadgets)  such  as  menus,  scroll  bars, 
buttons  and  icons.  Lapidary  therefore  supports  using  a  pre-defined  library  of 
widgets,  and  defining  a  new  library  with  a  unique  “look  and  feel.”  The  run-time 
behavior  of  all  these  objects  can  be  specified  in  a  straightforward  way  using 
constraints  and  abstract  descriptions  of  the  interactive  response  to  the  input 
devices.  Lapidary  genoaiizes  hrom  the  specific  example  pictures  to  allow  the 
graphics  and  behaviors  to  be  specified  by  demonstration. 


Figure  1:  The  workspace  window  of 
Lapidary  ( b),  where  a  node  of  a  graph 
editor  is  being  creased,  along  with  the 
standard  commands  ( a),  object  menus 
(c),  and  a  dialog  box  for  setting  con¬ 
straints  on  rectangles  (d). 


Graphical  objects  can  be  created  in  a  number  of  different  ways  using  Lapidary. 
As  shown  in  Figure  1,  the  standard  menus  provide  the  usual  range  of  graphical 
primitives,  so  objects  can  be  created  from  scratch. 
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Constraints 

A  cemral  feature  of  Lapidary  that  makes  it  appropriate  for  creating  run-time  ap- 
j^Kadon  graphics  is  the  use  of  constraints.  Constraints  allow  the  designer  to 
specify  a  reladon  between  a  graphic  objea  and  other  objects  in  the  scene,  and 
have  that  relation  maintained  at  run-time  by  the  system.  If  a  consoaint  is  one  of 
a  standard  set,  then  it  can  be  specified  easily  using  the  Lapidary  menus  (see 
Figure  1-d).  These  menus  support  having  objects  be  connected  on  their  edges  or 
m  the  middle,  with  o{Kional  offsets.  The  sizes  of  objects  can  also  be  related. 
There  are  different  windows  showing  the  constraints  for  lines  and  a  few  other 
objects.  Experience  with  Peridot  demonstrates  that  these  simple  types  of 
constraints  make  up  the  vast  majority  of  those  needed  in  typical  user  interfaces. 

Stnnetimes,  designers  want  to  use  relationships  that  cannot  be  created  out  of 
these  simple  choices.  In  that  case,  the  Custom  option  is  selected,  and  the  de¬ 
signer  is  allowed  to  type  in  an  arbitrary  Common  Lisp  expression  specifying  the 
coostraint  using  the  C32  system  (discussed  below). 

Unlike  Peridot,  Lapidary  currently  does  not  try  to  infer  the  graphical  constraints. 
Instead,  they  must  all  be  specified  explicitly  using  the  dialog  boxes.  With 
Lapidary,  we  wanted  to  concentrate  on  creating  a  practical  tool  that  extends  the 
range  of  interfaces  that  can  be  produced,  and  the  constraint  inferencing  in  Peridot 
was  felt  to  be  too  risky  for  the  first  version.  Future  Garnet  tools  will  revisit 
this  issue. 

In  ortba  for  the  graphical  objects  to  be  useful  at  run-time,  the  specific  constraints 
must  be  generalized  to  work  on  run-time  objects,  rather  than  on  the  specific  ex¬ 
ample  objects  used  in  the  editor.  For  example,  in  Figure  1,  the  label  on  the 
nodes  should  change,  but  still  stay  centered,  as  the  node  is  replicated.  Thus,  the 
constrain''-  need  to  be  generalized  to  reference  objects  indirectly  through 
variables,  rather  than  by  using  specific  object  names.  To  do  this,  the  reference 
to  the  object  is  replaced  with  an  expression  that  calculates  the  desired  object,  and 
^ores  it  in  a  special  slot.  The  constraint  system  then  automatically  ensures  that 
the  constraints  change  whenever  the  slot  is  set  with  a  different  object. 

It  is  important  to  emphasize  that  Lapidary  makes  these  transformations  automat¬ 
ically.  The  user  interface  designer  never  sees  any  of  the  code.  Even  if  the  de¬ 
signer  created  custom  constraints  by  typing  Lisp  code,  the  references  in  the  ex¬ 
pression  can  be  to  example  objects  (selected  by  pointing  at  them  with  the 
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mouse),  and  the  system  will  convert  these  references  to  be  ^eral  variables 
where  appropriate. 

Another  way  that  Lapidary  generalizes  firom  the  examples  is  to  automatically 
make  cq>ies  of  objects  at  lun-time.  Fdr  example,  to  show  the  selection  in  a 
drawing  edittn*.  the  designer  might  draw  a  single  set  of  selection  handles  around 
an  example  object.  However,  at  run  tune,  multiple  objects  might  be  selectable, 
so  Lapidary  arranges  for  the  selection  handles  to  be  duplicated  at  iun>time  if  nec¬ 
essary. 

Interactive  behavior 

Although  it  is  useful  to  prototype  the  graphic  appearance  of  user  interfaces,  it  is 
much  more  useful  if  the  interactive  behavior  can  also  be  specified  easily. 
Lapidary  therefore  provides  this  capability.  In  order  to  edit  the  behavior  of 
objects,  or  to  add  behavior  to  new  objects,  we  have  encapsulated  a  number  of 
kinds  of  interactive  behavir^  into  “interactor”  objects  [Myers  90c],  each  of 
which  has  its  own  dialogue  box  for  qrecifying  properties.  For  example,  to 
change  which  mouse  button  operates  a  menu,  it  is  only  necessary  to  change  the 
button  indicated  in  the  dialogue  box. 

Often,  there  will  be  a  specific  object  that  serves  as  the  feedback  for  an  operation. 
For  example,  a  reverse-video  rectangle  might  move  over  the  items  in  the  menu 
to  show  which  is  the  current  selection.  In  other  cases,  the  objects  themselves 
should  change  to  be  the  feedback.  For  example,  the  currently  selected  item  in  a 
menu  might  be  shown  in  italics.  Another  use  is  to  have  buttons  move  to  cover 
their  shadows  (and  therefore  look  more  “3-D”),  as  in  the  Motif  and  Garnet  look 
and  feels.  In  this  case,  the  desired  changes  can  be  shown  by  demonstration.  To 
specify  the  changes  by  demonstration,  first  the  designer  selects  the  objects  that 
will  change,  and  then  hits  a  button  in  the  dialogue  box.  The  full  current  state  of 
the  selected  objects  is  remembered.  Next,  the  designer  edits  the  objects  in 
whatever  way  desired,  for  example  to  make  the  string  be  italic.  Then,  another 
button  is  hit,  and  Lapidary  creates  a  constraint  that  will  choose  between  the  two 
values  based  on  whether  the  object  is  selected  or  not  Changes  can  be  made  to  as 
many  properties  as  desired,  and  correct  cemstraints  will  be  created  for  all  of  them. 


Summary 

Through  the  use  of  demonstrational  techniques.  Lapidary  is  able  to  allow  the  de¬ 
signer  to  interactively  create  far  more  of  the  user  interface  than  any  other  tool. 


In  particular,  new  widgets  and  application-specific  (Ejects  can  be  created. 
Demoostiatioaal  techniques  are  auciai  since  these  objects  all  are  parameterized 
and  will  change  dynamically  at  run  time,  so  it  is  only  possible  to  draw  exam¬ 
ples,  not  the  actual  objects  to  be  used.  These  examples  generalized  into  named 
prototypes  which  the  applications  can  then  make  instances  of  at  run  time. 


When  the  iconic  menus  in  Lapidary  are  not  sufilcient  for  specifying  the  desired 
constraints.  Garnet  provides  the  C32  spreadsheet  program  to  help  enter  more 
complex  constraints  [Myers  91a].  C32  can  also  be  used  stand-alone.  It  displays 
and  allows  the  user  to  edit  any  kind  of  object  and  constraint,  no  mauer  how  they 
were  created:  by  hand-coding,  by  using  Lapidary,  or  by  using  C32.  C32  stands 
for  CMU’s  Clever  and  Compelling  Contribution  to  Computer  Science  in 
Common  Lisp  which  is  Customizable  and  Characterized  by  a  Complete 
Coverage  of  Code  and  Contains  a  Cornucopia  of  Creative  Constructs,  because  it 
Out  Create  Complex,  Correct  Constraints  that  are  Constructed  Clearly  and 
Concretely,  and  are  Communicated  using  Columns  of  CeUs  that  are  Constantly 
Calculated  so  they  Otange  Continuously  and  Cancel  Confusion. 

Bgure  2  shows  a  typical  instance  of  C32.  Each  column  contains  a  separate  ob¬ 
ject  Rows  are  labeled  with  the  names  of  the  slots,  such  as  :  left ,  :  top, 

:  width,  :  height ,  :  visible,  etc.  Since  different  objects  can  have  dif¬ 
ferent  slots,  the  slot  names  are  repeated  in  each  column.  For  example,  lines 
have  slots  for  the  endpoints  ( :  xl ,  :  y  1 ,  :  x2 ,  :  y2)  but  rectangles  do  not. 
Also,  each  object’s  display  can  be  scrolled  separately,  so  each  has  its  own  scroll 
bar.  This  makes  the  spreadsheet  look  somewhat  like  a  multi-pane  browser  as  in 
Smalltalk. 


GARNET 


Second  Gamei  Compendium 


C32::R 


C32::X,xna 


m. 


wntmsmxsitrm 


m 


m 


l^tSl 


The  spreadsheet  cells  show  the  cunent  values  of  the  slots.  If  a  value  changes, 
then  the  display  will  be  inunediately  updated.  If  the  user  edits  the  value  in  the 
spreadsheet  cell,  the  object’s  slot  will  be  updated.  The  “P*  icon  by  some  slots 
in  Figure  2  means  that  the  slot  value  is  computed  from  a  formula.  Pressing  the 
mouse  on  the  icon  causes  the  constraint  expression  to  appear  in  a  different  win¬ 
dow.  The  expression  itself  can  be  edited  by  typing  or  other  techniques. 

Use  of  infsrencing 

It  is  sometimes  not  convenient  to  read  an  object  into  a  spreadsheet  column  just 
to  generate  a  reference  to  it.  Therefore,  a  command  will  place  into  the  current 
formula  a  reference  to  any  object  in  a  Garnet  window.  However,  selecting  a 
graphical  object  does  not  ^}ecify  which  slot  of  the  object  should  be  referenced. 
In  one  mode,  the  user  must  type  this  directly  or  select  a  slot  from  a  menu. 
However,  the  other  mode  uses  heuristics  to  guess  the  slot  from  the  example  by 
looking  at  the  slot  being  filled  and  where  the  mouse  is  pressed  in  the  selected  ob¬ 
ject.  For  example,  if  the  slot  is  :lef  t,  and  the  mouse  is  pressed  at  the  right  of 
an  object,  then  the  reference  will  be  to  the  right  of  the  object  For  the  rwidth 


Figure  2:  (a)  C32  viewing  three  ob¬ 
jects  (b).  The  scroll  bars  can  be  used 
to  see  more  slots  or  columns. 
Changing  the  window’s  site  will 
change  the  number  of  slots  and  ob- 
jeas  displayed  (the  number  of  rows 
and  columns).  Field  values  are 
clipped  if  they  are  too  long,  but  can 
be  scrolled  using  editing  commands. 
The  "F”  icon  means  that  the  slot  value 
is  computed  with  a  formula.  All  in¬ 
herited  slots  are  shown  in  italics  and 
marked  with  the  icon.  V/hen  a 
formula  is  inherited  the  value  is 
shown  in  a  regular  font  since  it  is  usu¬ 
ally  different  from  the  prototype's. 
The  inherited  icon  is  also  shown  next 
to  the  formula  icon  rather  than  next  to 
the  value. 


slot,  however,  the  same  press  would  generate  a  reference  to  the  width  of  the  ob 
ject  Unlike  Peridot,  C32  does  not  try  to  confirm  any  of  the  inferences,  but 
father  simply  inserts  the  text  into  the  ftamula.  If  the  guess  is  incorrect,  it  is 
easy  for  the  user  to  delete  the  text  and  type  the  ccnecdon. 

Once  a  complex  formula  is  created,  it  will  often  be  needed  in  a  slightly  different 
form  for  a  different  slot  or  a  different  object.  As  an  example,  suppose  the  user 
has  constructed  a  constraint  that  centers  an  object  horizontally  with  respect  to 
two  other  objects.  Now,  suppose  the  programmer  wants  to  center  the  object  ver¬ 
tically  also.  The  formula  could  be  copied  to  the  :  t  op  slot,  but  all  the  slot  ref¬ 
erences  need  to  be  changed  (:le£t  to  :top  and  :  width  to  ;  height). 
Therefore,  when  a  formula  is  copied,  C32  tries  to  guess  whether  some  slot 
names  should  be  changed.  This  uses  a  few  straightforward  rules  based  on  the 
slot  names  of  the  source  and  destination  slots.  Currently,  these  rules  are  hard¬ 
wired  into  the  code.  If  it  appears  that  slot  names  should  be  changed,  the  user  is 
queried  with  a  dialog  box,  and  if  the  answer  is  OK.  then  the  formula  is  modified 
autmnatically.  Since  this  is  a  more  radical  change  than  the  inferred  slots  dis¬ 
cussed  in  the  previous  section,  it  seems  prudent  to  require  confirmation. 

Automatic  generalization 

Another  possibility  is  that  the  references  in  the  formula  should  be  generalized 
into  variables.  C32  therefore  provides  a  command  that  will  change  the  entire 
formula  into  a  function  that  takes  the  objects  and/or  slots  as  parameters.  The 
user  can  choose  the  names  for  the  function  and  for  the  variables.  C32  will  gen¬ 
eralize  objects,  slots,  or  both. 

The  intelligent  copying  and  generalizing  in  C32  helps  the  user  generate  correct 
constraints  by  example.  Without  these  aids,  it  is  quite  common  to  forget  to 
change  one  or  more  of  the  references  when  formulas  are  copied.  Generalizing 
also  helps  the  programmer  decrease  the  size  of  the  code  by  promoting  the  reuse 
of  existing  formulas. 


Gilt .  .  ,  ,  Gilt  is  an  interface  builder  that  allows  dialog  boxes  and  other  windows  to  be 

created  interactively  by  choosing  widgets  from  a  palette  and  putting  them  into  a 
window  using  a  mouse  [Myers  9 Id).  Gilt  is  similar  to  many  other  interface 
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builders,  including  tbe  NeXT  Interface  Builder.  Rrototyper  from  SmethersBames 
for  the  Macintosh,  etc.  Gilt  stands  for  the  Q^met  Interface  Layout  lool. 

Demonsttational  techniques  have  been  added  to  GQt  in  two  places:  to  infer  graph* 
ical  styles  from  examples,  and  to  infer  transformations  of  data  and  dependencies 
to  minimize  the  number  of  call-back  procedures. 

Graphical  atylaa  in  Gilt 

In  most  toolkits,  the  widgets  have  many  properties  that  the  designer  can  set, 
such  as  the  color,  font,  label  string,  orientation,  size,  the  minimum  and 
maximum  values  of  a  range,  etc.  Many  widgets  in  the  Motif  widget  set,  for 
example,  have  nearly  SO  different  properties  that  can  be  set.  Most  interface 
builders,  including  Gilt,  provide  “property  sheets”  that  allow  the  designer  to 
specify  the  desired  values.  However,  it  can  be  quite  difficult  and  time  consuming 
to  find  and  set  all  of  the  appropriate  properties.  To  show  the  'tiagnitude  of  the 
problem,  many  applications  contain  over  2000  widgets,  and  tfiC  properties  for 
each  must  be  set  in  a  consistent  manner.  A  study  has  shown  that  achieving 
consistency  in  an  interfece  is  a  frequently  cited  problem  [Myers  92c]. 

Another  problem  for  interface  designers  is  laying  out  the  widgets  in  the  window. 
When  the  designer  places  widgets  with  the  mouse,  they  tend  to  be  uneven  and 
look  sloppy.  Therefore,  most  builders  provide  grids  and  alignment  commands. 
However,  these  can  be  clumsy  to  use,  and  they  do  not  ensure  that  different  dialog 
boxes  will  have  a  consistent  alignment  (for  example,  that  the  titles  are  always 
centered  at  the  top  of  the  window). 

To  help  solve  these  problems.  Gilt  introduces  the  notions  of  Graphical  Tabs  and 
Graphical  Styles  into  an  interface  builder,  which  are  more  completely  described 
in  [Hashimoto  92].  These  are  based  on  the  styles  and  tabs  in  text  editors  such  as 
Microsoft  Word.  A  “graphical  tab”  is  simply  a  horizontal  or  vertical  position  in 
the  graphics  window  to  which  objects  can  be  aligned.  A  “graphical  style”  is  a 
named  set  of  properties,  which  can  be  applied  to  widgets.  The  designer  can  edit  a 
widget  so  it  has  the  desired  properties,  select  it.  and  then  define  a  named  style 
based  on  it.  The  values  of  the  properties  and  the  positions  of  the  widgets  will  be 
associated  with  that  style  name.  The  style  can  then  be  applied  to  other  widgets. 

Furthermore,  Gilt  will  try  to  automatically  guess  when  to  apply  a  style,  so  the 
designer  does  not  have  to.  By  guessing  the  appropriate  properties  and  layout. 
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Gilt  makes  the  user  interface  design  process  significantly  faster,  since  users  can 
quickly  and  imprecisely  place  widgets,  and  the  system  will  automatically  neaten 
tbem.  Since  the  inferencing  is  based  on  the  styles  the  user  has  defined,  rather 
than  based  on  global,  default  rules,  as  in  earlier  systems  like  Peridot  and  Druid 
[Singh  90],  the  infetied  properties  and  posidons  are  more  likely  to  be  correct 

These  features  in  Gilt  are  classified  as  ''demonstradonal”  because  the  user  defines 
a  style  by  example  on  a  particular  widget,  but  the  style  is  automatically  general¬ 
ized  so  it  will  work  on  any  of  a  set  of  widget  types. 

A  graphical  style  includes  a  set  of  widget  properties,  and  optionally  some  posi¬ 
tion  informadon  as  well.  To  create  a  new  style,  the  designer  modifies  a  widget 
to  the  desired  appearance  using  the  convendonal  property  sheets,  selects  that 
widget,  and  then  issues  the  Define  Style  command.  The  designer  must 
then  type  a  style  name  into  the  Style  edidng  window  that  will  appear.  Gilt 
compares  the  widget's  current  properdes  with  the  default  values  for  that  widget 
and  copies  all  that  are  different  Styles  can  also  include  position  information. 
For  example,  a  designer  might  specify  that  objects  with  the  Main-Title- 
Sty  la  should  use  a  large  bold  font,  and  be  centered  at  the  top  of  the  window. 
The  posidon  informadon  for  styles  can  either  be  with  respect  to  a  graphical  tab 
stop,  or  reladve  to  a  previously  created  object 

Inferring  styles 

Although  the  styles  mechanism  as  described  above  is  already  quite  useful,  Gilt 
goes  further  and  tries  to  automadcally  determine  when  a  particular  style  is  ap¬ 
propriate.  The  style  control  window  (Figure  3)  provides  three  options:  no  infer¬ 
encing  of  styles,  styles  applied  immediately  when  they  are  inferred,  or  a  prompt- 
first  mode  where  the  designer  is  asked  if  the  style  should  be  applied,  as  in  Peridot 
and  Druid  [Singh  90],  If  the  system  usually  infers  the  correct  style,  then  the 
immediate  mode  will  be  the  most  efficienL 


79- 


Second  Garnet  Compendium 


GARNET 


rilttxuBM:  I /usr/bam/ emu-sty les 


Read  I  Save  I  Clear 


Guessing:  ^  ^  Immediate 

Prompt  First 

^  OHT 

Set  Style  [  Define  Style!  Edit  Style  (  Edit  TabStop 


Try  Again  I  Undo 


Style  of  Selec±ed  Object:  Main-Title-Style 


When  inferencing  is  on.  Gilt  tries  to  infer  a  new  style  whenever  a  widget  is  cre¬ 
ated  or  moved.  The  algorithm  looks  for  styles  that  aHect  the  same  type  as  the 
widget,  and.  if  the  style  has  a  position  component,  then  it  checks  how  close  the 
widget  matches  the  style’s  position.  The  types  that  styles  are  associated  with 
include  strings,  button  objects  (including  radio  buttons  and  check  boxes),  nu¬ 
meric  sliders  (including  both  sliders  and  scroll  bars),  text  input  fields,  etc.  A  list 
is  created  of  all  the  styles  that  match,  sorted  from  most  likely  to  least  likely. 


Figure  3:  The  main  style  control 
window.  This  allows  styles  to  be  read 
and  written  to  a  file,  and  style  guess¬ 
ing  to  be  turned  on  and  off.  Also,  the 
style  of  the  selected  object  is  always 
echoed  at  the  bottom  of  the  window. 


Any  inferencing  system  will  sometimes  guess  wrong.  Thus,  it  is  important  to 
provide  appropriate  feedback  so  the  users  are  confident  that  they  are  in  control 
and  know  what  Gilt  is  doing.  In  immediate  mode,  the  first  style  on  the  style  list 
is  immediately  applied  to  the  graphics,  and  the  name  of  the  style  is  shown  at  the 
bottom  of  the  style  control  window  (Figure  3).  The  widget  will  also  jump  to 
the  inferred  position  and  change  appearance.  If  the  inferred  style  is  not  correct, 
the  designer  can  hit  the  ‘Try  Again”  buuon,  which  will  remove  the  guessed  style 
and  instead  apply  the  next  style  in  the  sorted  list.  This  can  be  repeated  until 
there  are  no  more  styles  in  the  list.  The  “Undo”  button  can  also  be  hit  to 
remove  the  guessed  style,  and  return  the  widget  to  its  original  position  and 
properties.  In  prompt-first  mode,  the  sorted  list  of  all  the  inferred  styles  is  pre¬ 
sented  in  a  window,  with  the  most  likely  selected.  The  designer  can  select  a  dif¬ 
ferent  style,  if  necessary,  and  then  hit  OK  or  Cancel.  When  a  style  is  defined,  it 
immediately  becomes  a  candidate  for  inferencing.  This  is  very  useful  when  a 
number  of  widgets  will  all  be  created  using  the  same  style. 
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Editing  styles 

When  a  style  is  applied  to  a  widget,  either  explicitly  or  inferred.  Gilt  sets  up 
appropriate  pointers  and  back  pointers  so  that  if  the  style  is  ever  edited,  ail 
widgets  using  that  style  are  immediately  updated. 

Styles  can  be  edited  in  two  ways.  A  property  sheet  can  be  displayed  which 
shows  the  current  values  of  the  properties  for  the  style,  and  this  can  be  edited  di¬ 
rectly.  This  property  sheet  has  the  same  format  as  the  ones  for  the  standard  wid¬ 
gets.  The  positions  associated  with  the  style  can  be  edited  using  the  appropnate 
dialog  boxes. 

Alternatively,  the  designer  um  edit  the  styles  in  the  same  way  as  they  were  cre¬ 
ated:  by  working  on  example  widgets.  Whenever  a  widget  is  edited  that  has  al¬ 
ready  been  defined  to  be  of  a  particular  style.  Gilt  pops  up  a  dialog  box  asking  if 
the  edit  should  change  the  style  itself.  The  other  alternatives  are  to  make  the 
widget  no  longer  belong  to  the  style,  or  to  cancel  the  change  and  return  the  ob¬ 
ject  to  its  appearance  befeue  the  edit  was  attempted. 

In  the  future,  we  plan  to  add  the  ability  to  have  objects  use  a  particular  style 
with  exceptions,  but  this  is  a  complex  problem  [Johnson  88].  Some  of  the  is¬ 
sues  are  whether  to  copy  the  atuibutes  or  retain  the  link  to  the  original  style, 
what  to  do  to  a  style  when  the  style  it  inherits  from  is  changed,  and  whether  to 
save  the  inhcriiance  links  in  the  style  files,  or  write  out  all  the  style  information 
to  each  file. 

Minimizing  call-back  procaduras  In  Gilt 

Conventional  toolkits  today  require  the  programmer  to  attach  call-back  proce¬ 
dures  to  most  buttons,  scroll  bars,  menu  items,  and  other  widgets  in  the  inter¬ 
face.  These  procedures  are  called  by  the  system  when  the  user  operates  the  wid¬ 
get  in  order  to  notify  the  application  of  the  user’s  actions.  Unfortunately,  real 
interfaces  contain  hundreds  or  thousands  of  widgets,  and  therefore  many  call-back 
procedures,  most  of  which  perform  uivial  tasks,  resulting  in  a  maintenance 
nightmare.  Gilt  allows  the  majority  of  these  procedures  to  be  eliminated  [Myers 
91d].  The  user  interface  designer  can  specify  by  demonstration  many  of  the 
desired  actions  and  connections  among  the  widgets,  so  call-backs  are  only  needed 
for  the  most  significant  application  actions.  In  addition,  the  call-backs  that 
remain  are  completely  insulated  from  the  widgets,  so  that  the  application  code  is 
better  separated  from  the  user  interface. 


We  have  observed  that  many  of  the  caU*back  procedures  are  actually  used  to  filter 
tire  values  from  widgets  and  connect  widgets  to  each  ocher,  ratirer  than  to  perform 
real  appUc^on  work.  By  identifying  some  common  tasks  that  call-backs  are 
used  for,  and  providing  other  methods  for  handling  the  tasks,  we  have  been  able 
to  eliminate  the  need  for  most  call-backs.  The  tasks  can  be  classified  into  the 
following  categmies: 

Preparing  the  data  for  applications.  Often,  call-backs  are  used  to 
convert  the  values  that  the  widgets  return  into  a  form  that  the  application 
wants.  This  may  involve  converting  the  type  of  a  value,  for  example 
from  a  string  to  an  enumerated  type,  or  it  may  involve  combining  the 
values  from  multiple  widgets  into  a  single  record  structure. 

Error  checking.  Before  the  data  is  passed  to  the  application,  some  error 
checking  of  it  is  often  needed,  along  with  appropriate  messages  when 
there  is  an  error. 

Preparing  data  to  be  shown  to  the  user.  Another  set  of  procedures 
is  usually  needed  to  set  the  widgets  with  appropriate  default  values, 
which  are  often  dynamically  detennined  by  the  application.  For  exam¬ 
ple,  when  a  color  dialog  box  is  displayed,  the  widgets  in  it  will  usually 
need  to  be  set  to  the  color  of  the  currently  selected  object  In  some 
cases,  it  may  even  be  necessary  to  change  the  number  of  widgets  in  the 
dialog  box  each  time  it  is  displayed,  fm  example,  if  a  button  is  needed 
fev  each  application  data  valire. 

Internal  control.  Many  call-backs  are  used  to  control  connections  be¬ 
tween  user  interface  elements,  which  require  little  application  interven¬ 
tion.  For  example,  these  procedures  might  cause  a  widget  to  be  disabled 
(gray)  when  a  radio  buaon  is  selected,  ex  cause  one  dialog  box  to  appear 
when  a  button  in  another  is  hit. 

Gilt  provides  a  standard  style  of  window  that  allows  the  filter  expressions  to  be 
entered.  The  goal  is  to  minimize  the  amount  of  code  that  needs  to  be  typed  to 
achieve  the  required  transformation.  Therefore,  much  of  the  filter  expression  is 
generated  automatically  when  the  designer  demonstrates  the  desired  behavior. 
Other  parts  can  be  entered  by  selecting  items  from  menus.  As  a  last  resort,  the 
designer  can  type  the  required  code.  If  a  call  to  an  application  function  is  neces¬ 
sary  in  a  filter  expression,  Gilt  makes  sure  that  the  procedure  is  called  with  ap- 
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pn)(viate  hi^-levet  parameters,  rather  than  such  things  as  a  widget  pointer  or  the 
string  labels.  Th*'^  ‘‘‘t  cail-backs  that  remain  are  completely  insulated  from  the 
user  interface. 

Gilt  tries  to  automatically  pick  the  ^propriate  transformation.  There  are  two 
techniques  used  to  guess  what  is  appropriate.  First,  the  designer  can  type  an  ex¬ 
ample  value  into  the  Resulting  Filtered  Value  Held  at  the  bottom  of 
the  Exported  value  Control  window  (Figure  4-a).  In  this  case.  Gilt 
will  try  to  guess  a  transformation  that  will  convert  the  current  unfiitered  value 
into  the  specified  value.  If  none  of  the  built-in  transformations  is  appropriate, 
then  Gilt  creates  a  case  statement  The  designer  can  then  operate  the  widget  to 
put  it  into  different  states  (and  therefore  to  change  the  unfiitered  value),  and  type 
the  desired  filtered  value  fcx  each  case.  This  allows  arbitrary  transformauons 
(e.g.,  converting  the  German  "Fettdruck"  or  the  French  "Gras"  to 
:BOIiD).  The  resulting  code  for  the  filter  is  shown  in  the  Filter 
Expression  window. 

The  second  option  is  used  when  the  designer  enters  a  procedure  into  the  filter  ex¬ 
pression.  and  then  selects  a  widget  to  supply  the  value  to  a  parameter  of  the  pro¬ 
cedure.  Here.  Gilt  tries  to  find  an  appropriate  transformation  so  that  the  widget 
value  will  be  filtered  into  the  required  type  of  the  parameter.  A  Value 
Control  window  will  pop  up  to  confirm  each  transformation,  and  also  to  re¬ 
quest  the  designer  to  specify  the  transformation  if  Gilt  cannot  infer  it 

The  user  can  check  that  the  filter  expression  is  achieving  the  desired  result  in  two 
ways.  First,  the  interface  can  be  exercised  to  test  the  code.  Second,  the 
Filter  Expression  field  shows  the  Lisp  code  that  is  being  used.  In  the 
future,  we  will  be  investigating  other  techniques  for  showing  the  transformations 
that  will  be  usable  by  non-programmers.  For  example,  the  filter  expressions 
might  use  normal  arithmetic  expressions,  or  we  might  create  a  special  graphical 
programming  language. 
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Figur*  4:  (a)  The  Gilt  window  that 
allows  the  designer  to  control  how 
values  for  widgets  are  filured.  Many 
of  the  fields  are  filled  in  by  Gilt  as  the 
designer  demonstrates  the  desired  be¬ 
havior.  The  Unfilzered  Value 
shews  the  value  as  currently  provided 
by  the  widget  before  any  filtering. 

The  FilZer  Express  ion  is  the  Lisp 
expression  to  filter  the  value.  The  de¬ 
signer  can  hit  the  Use  Va  1  ue  of 
Ob  Jeez  button  to  insert  a  reference  to 
the  value  of  a  selected  object.  The  de¬ 
fault  filter  simply  copies  the  original 
value.  The  Resulz ing  Filtered 
Val  ue  field  shows  the  final  value  af¬ 
ter  the  filtering.  This  field  can  be 
edited  to  show  the  transformation  for 
the  current  widget  by  example,  ib) 
shows  the  filter  expression  after  a 
function  has  been  selected  from  a 
menu  and  the  widget  references  have 
been  filled  in.  (e)  shows  the  addi¬ 
tional  windows  that  appear  to  confirm 
the  transformations  that  are  inferred 
for  the  widgets  that  are  referenced  in 
<b). 
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For  enabling  and  disabling  widgets,  similar  techniques  are  used.  One  of  the 
most  common  dependoicies  is  to  enable  and  disable  widgets  based  on  the  values 
of  other  widgets.  To  specify  this,  the  designer  can  tolerate  a  widget  to  have  the 
appropriate  value,  then  enable  or  disable  the  dependent  widget,  and  Gill  will  fill 
in  the  values  for  the  Change  my  Enable  expression.  In  trying  to  guess  ap¬ 
propriate  control  expressions  for  dependent  slots.  Gilt  knows  about  check  boxes 
and  radio  buttons  being  on  or  off.  text  fields  being  empty  or  having  a  value,  and 
numbers  being  xero  or  non-zero.  In  addition,  if  the  Change  my  Enable 
window  is  for  a  set  of  selectable  items  (such  as  a  menu  or  a  panel  of  buttons), 
the  controlling  widget  can  return  a  list  of  values,  each  element  of  which  controls 
an  item. 

All  the  other  properties  of  widgets  can  be  controlled  in  the  same  way  as  en¬ 
abling.  Widgets  can  be  made  to  be  visible  and  invisible  by  bringing  up  a 
Change  my  Visible  window.  Similar  windows  control  properties  such  as 
color  and  font 

To  edit  the  value  of  any  of  the  filter  expressions  for  a  widget,  the  designer  can 
simply  select  the  widget  and  bring  up  the  appropriate  Control...  or 
Change  my . . .  window.  The  designer  can  then  edit  the  text  of  the  expres¬ 
sion.  Alternatively,  if  the  user  demonstrates  new  transformations,  these  will  re¬ 
place  the  existing  ones  as  appropriate. 

<  lad*  creates  dialog  boxes  from  just  a  list  of  their  contents  [Vandcr  Zanden  90].  It 
uses  general  rules  from  graphic  design  as  well  as  look-and-feei-specific  rules  in 
order  to  create  a  pleasing  presentatimi.  Jade  is  useful  when  an  application 
contains  a  large  number  of  dialog  boxes  (so  that  using  Gilt  would  be 
inconvenient),  or  when  the  contents  of  a  dialog  box  is  not  known  in  advance  so 
the  dialog  box  needs  to  be  dynamically  generated  (so  using  Gilt  would  be 
impossible).  Jade  stands  for  the  Judgment-based  Automatic  dialog  Editor. 

The  demonstrational  aspect  of  Jade  is  that  it  will  automatically  generate  the  rules 
that  control  the  layout  frxjm  examples  of  the  desired  picture.  An  interactive  edi¬ 
tor  is  being  created  that  will  allow  the  designer  to  show  the  system  how  the  in¬ 
terface  should  look.  This  part  of  the  system  is  still  under  development 
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Garnet  contains  built-in  support  for  interfaces  including  gestures.  A  gestural 
interface  vxs  the  path  that  the  mouse  goes  through  in  cvder  to  determine  the 
command.  For  example,  the  user  might  draw  an  “X”  over  an  object  to  cause  it 
to  be  deleted,  or  an  “L”  shaped  motion  might  mean  to  create  a  new  rectangle, 
whereas  a  circular  motion  might  mean  create  a  new  circle.  The  gestural  mecha¬ 
nism  in  Garnet  uses  an  algorithm  that  is  trainable  [Rubine  91a].  This  means 
that  the  designa  gives  examples  of  the  desired  gesQires,  and  the  system  uses 
statisticai  techniques  to  match  the  end-user’s  gestures  against  the  examples  to 
decide  which  gesture  the  end-user  is  giving. 


Unlike  Peridot,  the  goal  in  Garnet  is  not  specifically  to  investigate  demonstxa- 
tional  techniques,  but  rather  to  create  a  usable  and  evident  collection  of  tools  to 
create  user  interfaces.  However,  we  have  found  that  demonstrational  techniques 
are  very  effective  for  extending  the  boundaries  of  what  can  be  acccunplished  by 
direct  manipulation.  Inferencing  is  used  in  most  of  our  demonstrational  sys¬ 
tems,  but  it  is  not  particularly  sophisticated.  In  all  cases,  just  one  or  two  rules 
are  needed  to  decide  how  and  when  to  generalize.  Ail  the  techniques  are  applica¬ 
tion-specific  and  ad-hoc.  which  suggests  that  some  general-purpose  toolkit  con¬ 
taining  demonstrational  techniques  would  probably  not  be  helpful.  As  with 
other  demonstrational  interfaces,  the  primary  problems  in  Garnet  have  been  how 
to  provide  ^Tfnxjpriate  feedback  for  the  generalizations  so  the  users  are  comfort¬ 
able  with  them,  and  how  to  allow  editing.  In  most  cases,  the  technique  used  cur¬ 
rently  is  just  to'show  the  Lisp  code  that  was  inferred,  and  require  that  the  user  di¬ 
rectly  edit  the  code,  but  we  plan  m  investigate  mote  sophisdcated  methods  in  the 
future. 


The  Garnet  research  is  sponsored  by  the  Avionics  Lab,  Wright  Research  and 
Development  Center,  Aeronautical  Systems  Division  (AFSQ,  U.  S.  Air  Force, 
Wright-Patterson  AFB,  OH  45433-6543  under  Contract  F33615-90-C-1465. 
Arpa  Order  No.  7597. 

The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors 
and  should  not  be  interpreted  as  representing  the  onicial  policies,  either  expressed 
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ABSTRACT 

Conventional  loclkits  today  require  the  programmer  to  at¬ 
tach  call-back  procedures  to  most  buttons,  scroll  bars, 
menu  items,  and  other  widgets  in  the  interface.  These 
procedures  are  called  by  the  system  when  the  user  operates 
the  widget  in  order  to  notify  the  application  of  the  user’s 
actions.  Unforuinately,  real  interfaces  contain  hundreds  or 
thousands  of  widgets,  and  therefore  many  call-back 
procedures,  most  of  which  perform  trivial  tas^,  resulting 
in  a  maintenance  nightmare.  This  paper  describes  a  system 
that  allows  the  majority  of  these  procedures  (o  be 
eliminated.  The  user  interface  designer  can  specify  by 
demonstration  many  of  the  desired  actions  and  connections 
among  the  widgets,  so  call-backs  are  only  needed  for  the 
most  significant  application  actions.  In  addition,  the  call¬ 
backs  that  remain  are  completely  insulated  from  the 
widgets,  so  that  the  application  code  is  better  separated 
from  the  user  interface. 

KEYWORDS:  Call-Back  Procedures.  Dialog  Boxes. 
UIMSs,  interface  Builders. 

1.  Introduction 

The  Gilt  Interface  Builder  allows  dialog  boxes  and  similar 
user  interface  windows  to  be  created  by  selecting  widgets 
from  a  palette  and  laying  them  out  using  a  mouse.  More 
interestingly.  Gilt  provides  a  variety  of  mechanisms  to 
reduce  the  number  of  call-back  proc^ures  that  arc  neces¬ 
sary  in  graphical  interfaces.  A  “call-back"  is  a  procedure 
defined  by  the  application  programmer  that  is  called  when 
a  widget  is  operated  by  ihe  end  user.  A  ‘‘widget’’  is  an 
interaction  technique  such  as  a  menu,  button  or  scroll-bar. 
A  collection  of  widgets  is  called  a  toolkit.  Examples  of 
toolkits  are  the  Macintosh  Toolbox,  the  Motif  and  Open- 
Look  toolkits  for  X  windows,  and  NeXTStep.  Most 
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toolkits  today  require  the  programmer  to  specify  call-backs 
for  almost  every  widget  in  the  interface,  and  some  widgets 
even  take  more  than  one  call-back.  For  example,  the  slider 
widget  in  Motif  has  two  call-backs,  one  for  when  the  in¬ 
dicator  is  dragged  and  one  for  when  it  is  released. 

A  typical  user  interface  for  a  moderately  complex  program 
will  contain  hundreds  or  even  thousand  of  widgets.  For 
example,  the  VUIT  program  from  DEC  uses  over  2500 
widgets.  This  means  that  the  programmer  must  provide 
many  call-back  procedures.  To  add  to  the  complexity,  each 
type  of  widget  may  have  its  own  protocol  for  what 
parameters  are  passed  to  the  call-back  procedures,  and  how 
the  procedures  access  data  from  the  widget. 

The  use  of  all  of  these  call-backs  means  that  the  user  inter¬ 
face  code  and  the  application  code  are  not  well  separated  or 
modularized.  In  particular 

•  The  call-backs  closely  tie  the  application  code  to  a  par¬ 
ticular  toolkiL  Since  each  toolkit  has  its  own  protocol  for 
how  the  call-backs  are  called,  moving  an  application 
from  one  toolkit  to  another  (e.g..  ttom  Motif  to  Open- 
Look)  can  requue  recoding  hundreds  of  procedures. 

•  The  call-backs  make  maintaining  and  changing  the  user 
interface  very  difncult.  Changing  even  a  small  pan  of  an 
interface  often  requires  rewriting  many  procedures.  Even 
li  a  graphical  interface  builder  is  used  to  change  the 
widgets,  the  call-backs  must  be  hand-edited  afterwards  if 
widgets  are  added,  deleted,  or  modified. 

•  The  call-backs  often  are  passed  the  text  labels  shown  to 
the  user,  so  if  the  natural  language  u.'^ed  in  the  dialog  box 
IS  changed  (e.g..  from  English  to  French),  the  values 
passed  to  the  call-backs  will  change,  requiring  the  ap¬ 
plication  code  to  be  edited. 

We  have  observed  that  many  of  the  call-back  procedures 
are  actually  used  to  filter  the  values  from  widgets  and  con¬ 
nect  widgets  to  each  other,  rather  than  to  perform  real  ap¬ 
plication  work.  By  idcntifyiiig  some  common  tasks  that 
call-backs  are  used  for,  and  providing  other  methods  for 
handling  the  tasks,  we  have  been  able  to  eliminate  the  need 
for  most  call-backs.  The  tasks  can  be  classified  into  the 
following  categories: 
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Preparing  the  data  for  appUcadoos.  Ofien,  call-backs 
are  used  to  conveit  the  values  that  the  widgets  return 
iiuo  a  fonn  that  the  application  wants.  This  may  in¬ 
volve  converting  the  type  of  a  value,  for  example  Crom 
a  string  to  an  emtniented  type,  or  it  may  involve  com¬ 
bining  the  values  from  multiple  widgets  into  a  single 
record  stnicoBe. 

Error  checking.  Before  the  dau  is  passed  to  the  applica- 
.  tion,  some  error  checking  of  it  is  often  needed,  along 
with  aiqnopriaie  messages  when  there  is  an  error. 

Preparing  data  to  be  showa  to  the  user.  Another  set  of 
procedures  is  usually  needed  to  set  the  widgets  with 
appropriate  default  values,  which  are  often  dynami¬ 
cally  determined  by  the  applicaiioa  For  example, 
whra  a  color  dialog  box  is  displayed,  the  widgets  in  it 
will  usually  need  to  be  set  to  the  color  of  the  currently 
selected  object.  In  some  cases,  it  may  even  be  neces¬ 
sary  to  change  the  number  of  widgets  in  the  dialog  box 
each  time  it  is  displayed,  for  example,  if  a  button  is 
needed  for  each  application  data  value. 

Internal  control.  Many  call-backs  are  used  to  control  con¬ 
nections  between  user  interfiKe  elements,  which  re¬ 
quire  little  application  iiuervention.  Fctr  examprie, 
these  procedures  might  cause  a  widget  to  be  disabled 
(grey)  when  a  radio  button  is  select,  or  cause  one 
dialog  box  to  appear  when  a  button  in  another  is  hit 

Gilt  provides  a  standard  style  of  window  that  allows  the 
filter  expressions  to  be  entered.  The  goal  is  to  minimize 
the  amoum  of  code  that  needs  to  be  typed  to  achieve  the 
required  inuisfomution.  Therefore,  much  of  the  filter  ex- 
pressran  is  generated  automaticaliy  when  the  designer 
demonstrates  the  desired  behavior.  Other  parts  can  be  en¬ 
tered  by  selecting  items  (tom  menus.  As  a  last  resort,  the 
designer  can  type  the  required  code.  If  a  call  to  an  applica¬ 
tion  function  is  necessary  in  a  filler  expression.  Gill  makes 
sure  that  il»  procedure  is  called  with  ap^nopriaie  high-level 
parameters,  rather  than  such  things  as  a  widget  pointer  or 
the  string  iabels.  Thus,  the  call-backs  that  remain  are  com¬ 
pletely  insulated  from  the  user  interface. 

Gilt  is  a  pan  of  the  Ganiet  system  [8].  Garnet  is  a  com¬ 
prehensive  user  interface  development  environment  con¬ 
taining  many  high-level  tools,  including  Gilt,  the  Lapidary 
interactive  design  tool  (7],  the  C32  sprcufshcct  system  {9], 
etc.  Gamci  also  contains  a  complete  toolkit,  which  uses 
constraints  (151  and  a  prototype-instance  object  model. 
Gill  stands  for  the  Garnet  Interface  layout  Tool,  and  it 
supports  interfaces  built  using  cither  ihe  Garnet  look-and- 
feei  widget  set  or  the  Motif  look-and-feel  widget  set.'  Gilt 
uses  CommonLisp,  but  the  ideas  presented  here  are  ap¬ 
plicable  to  interface  builrter  tools  using  conventional  com¬ 
piled  languages. 
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2.  Related  Work 

Of  course,  there  are  a  large  number  of  commercial  and 
research  interface  builden  that  lay  out  widgets,  including 
DialogEdiior  [3],  the  Proiotyper  for  die  Macintosh  [13],  the 
NeXT  Interface  Builder.  UIMX  for  Motif,  and  Druid  (12]. 
However,  these  only  have  limited  mechanisms  for  reducing 
call-backs.  Many  of  them  suppon  tnnsiiions  &om  one 
dialog  box  to  another,  and  NeXT  allows  the  output  value  of 
one  widget  to  be  connected  to  the  input  o£  another,  if  no 
filtering  is  needed.  Druid  adds  the  aUlity  to  set  the  initial 
values  for  widgets  (but  only  statically,  not  application  data 
dependem).  and  to  coUea  values  of  widgets  for  use  as  the 
parameter  to  a  procedure.  It  allows  the  designer  to  specify 
some  of  these  by  demonstration.  However,  in  Gilt,  sig¬ 
nificantly  more  of  the  user  interface  can  be  specified  with¬ 
out  requiring  call-backs,  the  call-backs  are  more  independ¬ 
ent  of  the  widgets,  and  a  uniform  framework  is  used  for  all 
filtering. 

A  primary  influence  on  Gill  is  the  Peridot  UlMS  (6]. 
Peridot  was  the  first  system  to  allow  the  designer  to  specify 
the  behavior  of  the  inierfiKe  by  demonstration.  Gift  uses 
sonte  of  the  techniques  in  Peridot  to  guess  the  appropriate 
transformaiions  based  on  the  example  values. 

The  filter  expressioas  that  the  designer  specifies  in  Gilt  are 
implemented  using  constraints.  A  coosoaim  is  a  relation- 
sh^  that  is  declared  once  and  then  maintained  by  the  sys¬ 
tem.  Constraints  have  been  used  by  many  systems,  staniflg 
with  Sketchpad  [14]  and  Tbinglab  [TbinglabToplas).  Uses 
of  constrairos  within  user  interface  toolkits  include  GROW 
[1],  Peridot  (6).  and  Apogee  (SI. 

Other  systems  have  allowed  the  designer  to  specify  the 
cemnections  between  the  user  interface  and  the  application 
procedures  at  a  high  level  The  Mickey  system  [111  uses 
specLJ  comments  in  the  procedure  definidon  to  d^ribe 
tte  connection  to  the  user  interface.  The  UIDE  system 
(4]  allows  the  application  procedures  to  be  defined  in  ad¬ 
vance,  and  generates  the  interface  partially  from  these.  Un¬ 
like  these  systems.  Gilt  requires  the  designer  to  specify  the 
graphics,  and  then  explicitly  attach  the  graphics  to  the 
procedures,  but  it  infers  the  mapping  between  the  values 
returned  by  the  widgets  and  the  values  desired  by  the 
procedures. 

3.  Example 

To  show  how  easy  it  is  to  define  dependencies  without 
writing  call-backs,  we  will  first  present  an  example  of 
creating  the  dialog  box  of  Figure  1.  There  are  a  number  of 
dependencies  in  this  reladveiy  simple  interface.  The  return 
value  of  the  dialog  box  is  a  font  object  If  one  of  the 
standard  fonts  is  selected,  then  the  corresponding  built-in 
font  object  should  be  reusned.  Otherwise,  the  return  value 
will  be  a  fom  specified  by  name,  so  Ihe  specified  fik 
should  be  opened,  and  a  new  foot  object  created  for  that 
file. 

Pint,  the  user  would  create  the  graphics  for  the  dialog  box 
by  selecting  the  widgets  fiom  a  palette  and  typing  in  the 
correct  labels,  in  the  convemiooal  diiea  manipulation  man- 
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Figure  1: 

A  foiu  selection  dialog  box  being  created  in  Gilt.  When 
(he  Standard  Pone  radio  button  is  prassed,  the 
Font  Nane  field  is  disabled  (grey),  aid  when  the 
Other  Font  radio  button  is  selected,  the  three  sets  of 
buttons  under  Standard  Font  (for  the  family,  face 
and  size  of  the  font)  become  disabl^ 


tier  as  with  other  interface  builders.  Next,  the  designer 
gives  meaningful  names  to  the  widgets  (e.g.,  the 
Bold/ Italic  radio  buttons  are  called  "face'*). 
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The  default  value  of  a  set  of  radio  buuons  is  the  string  label 
of  the  selected  button.  We  will  now  override  this  and  make 
the  value  of  the  Standard  Font  branch  instead  be  the 
appropriate  font  objea.  To  do  this,  we  bring  up  the  Gilt 
window  in  Figure  2-a.  When  it  is  brought  up,  it  initially 
shows  that  the  resulting  exported  value  from  the  widget  is 
the  same  as  the  widget’s  value.  To  get  the  appropriate  font 
object,  we  need  to  call  the  Gilt  function  get-standard- 
font,  so  we  choose  this  from  a  menu.  This  inserts  the 
function  call  into  the  filter  expression.  The  procedure 
should  be  passed  the  values  of  the  three  sets  of  widgets 
under  standard  Font.  Therefore,  we  select  the  three 
widget  sets  and  hit  the  Uae-value-of-Ob ject  button 
in  the  window.  This  inserts  references  to  all  the  selected 
objects  into  the  filter  expression,  resulting  in  Figure  2-b. 
The  references  arc  inserted  in  the  order  the  objects  were 
selected.  These  references  will  be  to  the  filtered  values  of 
the  widgets,  which  so  far  are  the  same  as  the  default  values: 
the  string  names  of  the  labels.  However.  Gilt  knows  that 
get-scandard-font  expects  Lisp  keywords  as  ar¬ 
guments  rather  than  strings  (a  "keyword"  is  an  atom 
prefixed  by  a  colon,  such  as  :bold).  Therefore,  Gilt  can 
tell  lhat  there  is  a  mismatch,  so  it  tries  to  determine  a  pos¬ 
sible  transformation.  Another  Exported  value 
Control  window  pops  up  for  each  of  the  selected 
widgets,  and  the  designer  can  check  that  the  inferred  trans¬ 
formations  are  correct  (Figure  2-c).  if  not,  the  designer  can 
give  additional  examples  or  explicitly  edit  the  generated 
code.  In  this  example,  however,  the  system  guesses  all 
cases  conectly,  so  the  designer  simply  hits  "OK"  on  all  of 
the  windows.  This  will  assen  constraints  so  that  the  fil¬ 
tered  values  of  the  widgets  will  be  keywords,  as  required. 

Now,  the  value  for  the  other  branch  must  be  set  The 
designer  selects  the  other  Font  radio  buuon  and  brings 
up  the  Exported  value  Control  window  for  it.  By 
selecting  the  get -font -from- file  function  from  a 
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Figure  2: 

(a)  The  Gilt  window  that  allows  the  designer  to  control 
how  values  for  widgets  are  filtered.  Many  of  the  Helds 
arc  filled  in  by  Gill  as  the  designer  demonstrates  the 
desired  behavior.  The  Un filtered  Value  shows 
the  value  as  currently  provided  by  the  widget  before  any 
filtering.  The  Filter  Expression  is  the  Lisp  ex¬ 
pression  to  niter  the  value.  The  designer  can  hit  the 
Use  Value  of  Ob  ject  buuon  to  insert  a  reference 
to  the  value  of  a  selected  object.  The  default  filter 
simply  copies  the  original  value.  The  Resulting 
Filtered  Value  Held  shows  the  final  value  after 
the  filtering.  This  field  can  be  edited  to  show  the 
Uansfonnation  for  the  ctorenl  widget  by  example,  (b) 
shows  the  niter  expression  after  a  function  has  been 
selected  from  a  menu  and  the  widget  references  have 
been  niled  in.  (c)  shows  the  additional  windows  that 
appear  to  conHim  the  transformations  that  are  inferred 
for  the  widgets  that  are  referenced  in  (b). 
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Figure  3: 

This  window  allows  the  designer  to  specify  the  handling 
of  error  values.  When  Other  Font's  nitered  value  is 
NIL,  the  first  error  siring  is  printed,  and  when  Other 
Font  is  the  special  value  :NOT-FONT,  the  second 
string  is  printed.  The  Use  Value  of  Object  but¬ 
ton  is  used  to  insert  a  reference  to  a  selected  object, 
here,  the  value  of  the  Font  Name  widget,  which  con¬ 
tains  the  current  file  name.  The  Another  Error 
Check  button  causes  another  If  value  Is  and 
Error  String  pair  to  appear. 


Figure  4: 

The  Gill  window  that  allows  the  designer  to  specify  that 
the  enable  propeny  of  a  widget  depends  on  other 
widgets.  When  the  Expression  returns  NIL,  the 
widget  IS  shown  "greyed -out.” 

menu,  then  selecting  the  Font  Name  widget,  and  finally 
hitting  the  Use  value  of  Ob  ject  button,  the  designer 
can  specify  the  appropriate  dependencies.  Since 
gec-£ont-f corn-file  cxjiccts  u  suing,  no  furtlicr 
transformations  are  needed.  If  the  font  is  not  found,  the 
get-f  ont-f  rom-f  lie  funt  on  returns  error  values,  so 
the  Error  Check  window  is  used  to  specify  the  handling 
of  iJtis  (Figure  3).  The  designer  types  the  appropriate  error 
return  values  and  response  suings  into  this  window. 

Next,  die  value  of  the  entire  dialog  box  is  specified  as  the 
value  of  the  pair  of  radio-luttons  Standard  Font  and 
Other  Font,  and  now  the  dialog  box  will  return  a  single 
value,  computed  based  on  the  settings  of  the  widgets. 

Finally,  the  designer  needs  to  specify  when  die  various 
widgets  should  be  disabled  (greyed  outi  First,  the  designer 
selects  the  Font  Name  text  field,  and  then  brings  up  the 
Change  my  Enable  window  (see  Figure  4).  Note  that 
this  window  has  the  same  general  fcHm  as  the  Value  Con¬ 
trol  window,  but  simply  conuols  a  different  propeny  of  the 
widgets  (the  enable  flag  rather  than  the  value).  Next,  the 


desi^r  selects  the  Other  Font  radio  button  and  hits 
the  Use  Value  Of  Object  button.  This  makes  the 
Font  Name  enabled  (not  grey)  when  Other  Font  is 
chosen.  Similarly,  the  family,  face  and  size  buoons  under 
Standard  Font  are  enabled  when  standard  Font 
is  selected. 

4.  Filtering 

Each  widget  in  Garnet  will  always  fust  compute  its  default 
value,  which  is  then  assigned  lo  the  widget’s  slot  (instance 
variable)  called  :  VALUE.^  This  value  can  then  be  filtered 
to  derive  the  value  seen  by  application  programs,  which  is 
set  into  the  slot  called  :  FILTERED-value.  This  is  im¬ 
plemented  as  a  constraint  that  sets  the  value  of  the 
:  FILTERED-VALUE  Slot  whenever  the  value  of  (he 
:  VALUE  slot  changes.  The  default  constraint  simply 
copies  the  value.  Experience  has  shown  that  most  filter 
expressions  are  rather  short,  often  only  one  or  two  lines. 
Sometimes,  it  will  be  necessary  lo  have  longer,  complex 
iransformaiions  or  access  to  application-specific 
functionality  and  data.  Here,  a  conventional  text  edimr 
would  be  used  u>  create  a  function  which  will  then  be 
called  by  the  filter  expression  entered  with  GiU.  However, 
(he  function  will  be  independent  of  the  particular  widgets 
used  since' Gill  provides  uansfonnations  of  ihe  arguments 
and  reuirn  values  from  the  function. 

As  was  shown  in  the  example.  Gilt  provides  a  number  of 
ways  u>  specify  the  appropriate  filtering  of  data  and  control 
in  user  interface,  so  the  application  code  is  independent 
of  the  particular  widgets  us^  atxl  the  label  strings  shown 
to  the  user.  All  of  these  uansformaiions  use  the  same, 
standard  Control  windows  shown  in  the  previous  ex¬ 
amples.  The  following  sections  show  how  the  various 
tasks  that  require  call-backs  in  other  toolkits  are  performed 
in  GiiL 

4.1  Preparing  Data  for  Applications 
Many  call-backs  in  widgets  simply  filter  the  output  value  to 
convert  it  to  a  farin  needed  by  the  application  program. 
For  example,  for  Figure  1,  you  might  need  as  many  as  13 
diffcrcru  call-backs  in  other  toolkits  to  generate  the  single 
font  value  U)  be  iciunicd.  hi  Gill,  liic  value  of  iliu  dialog 
box  IS  available  in  a  variable,  without  requiring  a  call-back. 

Unlike  most  loolkits.  Garnet  provides  values  for  groups  of 
widgets.  For  example,  the  default  value  of  a  radio  button 
set  is  the  name  of  ihe  radio  buuon  (hat  is  selected,  or  NIL  if 
none  are.  For  a  set  of  check  boxes  (that  allows  multiple 
selections),  the  value  is  a  list  of  the  selected  buttons.  Tlie 
innovation  in  GiU  is  ihat  the  designer  can  specify  alter¬ 
native  values  for  widgets.  In  the  example,  the  value  of  the 
pair  of  radio  buttons  Standard  Font/Other  Font 
will  be  a  font  object. 

Many  of  the  desired  transformations  of  the  values  can  be 
achieved  by  simple  type  conversions:  from  strings  to 
keywords,  atoms,  numbers,  etc.  Tlierefore,  Gilt  provides  a 
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number  of  built-in  data  (lansformaiions: 

•  String  to  Lisp  atom  (c.g.  "Bold"  to  '  BOLD). 

•  String  to  Lisp  keyword  (c.g.  "Bold"  to  :  BOLD). 

•  String  to  index  of  item  in  the  set  of  buttons  (e.g.  "Bold” 
toO). 

•  String  to  number  (e.g.  "10"  tolO). 

•  Integer  range  to  a  different  integer  or  (loai  range. 

Similar  transformations,  would  be  appropriate  for  a  builder 
generating  other  computer  languages,  like  C  or  Pascal, 
which  might  automaiksiUy  create  enumerated  types,  sets, 
bit  vectors,  or  named  constants. 

Gilt  tries  to  automatically  pick  the  appropriate  transfor¬ 
mation.  There  are  two  techniques  used  to  guess  what  is 
appropriate. 

First,  the  designer  can  type  an  example  value  into  the 
Resulting  Filteced  Value  field  at  the  bottom  of 
the  Exported  Value  Control  window  (figure  2-a). 
In  this  case.  Gilt  will  iry  to  guess  a  transformation  that  will 
convert  the  current  unfiitercd  value  into  the  specified  value, 
using  the  above  rules.  If  none  of  the  built-in  transfor¬ 
mations  is  appropriate,  then  Gilt  creates  a  case  statement. 
The  designer  can  then  operate  the  widget  to  put  it  into 
differem  states  (and  therefore  to  change  the  unflltered 
value),  and  type  the  desired  filtered  value  for  each  case. 
This  allows  arbitrary  transformations  (e.g..  converting  the 
German  "Faccdruck"  or  the  French  "Scas"  to 
;  BOLD).  The  resulting  code  for  the  filter  is  shown  in  the 
filter  Expression  window. 

The  second  option  is  used  when  the  designer  enters  a  pro¬ 
cedure  into  die  filter  expression,  and  then  selects  a  widget 
to  supply  the  value  to  a  parameter  of  the  procedure.  Here, 
Gilt  uies  to  find  an  appropriate  transformation  so  that  the 
widget  value  will  be  filtered  into  the  requited  type  of  the 
parameter.  This  is  the  technique  used  in  the  example.  A 
Value  Control  window  will  pop  up  to  confirm  each 
transformation,  and  also  to  request  the  designer  to  specify 
the  uansformation  if  Gilt  cannot  infer  it. 

A  number  of  standard  procedures  are  provided  in  a  pop-up 
menu,  so  the  designer  can  often  select  a  procedure  for  the 
filter  expression  rather  than  typing  it.  The  provided 
routines  will  transform  a  siring  into  a  file  pointer,  a  string 
into  a  font  pointer,  numbers  or  a  siring  into  a  color, 
keywords  into  a  font,  etc.  If  one  of  these  is  selected  from 
the  menu,  the  appropriate  code  is  entered  into  the  f  ilcec 
Expression  field.  Because  these  routines  take  abstract 
values  as  parameters,  and  return  a  value  of  the  appropriate 
type  (such  as  a  font  object),  the  implementation  of  the 
routines  is  entirely  independent  of  the  widgets.  In  fact, 
standard,  built-in  routines,  such  as  the  Lisp  function 
probe- file,  can  be  used  in  many  cases. 

Gilt  can  execute  the  filter  expressions,  including  any 
procedures  entered  bv  the  designer,  by  using  the  Lisp  inter¬ 
preter.  Therefore,  when  Gill  is  put  in  "run-mode”  the 
actions  will  happen  just  as  they  wUl  for  the  end  user.  Gilt 
first  checks  U)  make  sure  that  all  procedures  arc  defined,  in 
case  the  designer  has  entered  an  application-specific  proce¬ 
dure  that  is  not  implemented  yet.  !n  this  situation.  Gilt 


Figure  5: 

The  color  selection  dialog  box  created  using  Gik 
(naturally,  this  is  in  color  on  ihe  screen).  There  are  a 
number  of  dependencies  among  the  widgeis  that  were 
defined  by  demonstration.  If  one  of  the  color  buttons  on 
ihe  left  is  selected,  the  sliders  adjust  to  the  appropriate 
position  for  that  color,  tf  the  sliden  ue  moved,  the 
highlight  in  the  color  buttons  (here  shown  around 
Mocif-ocange),  goes  ui  the  appropriate  color  or 
goes  off.  The  rectangle  in  the  upper  cotter  always 
shows  the  current  color.  The  filiered  value  of  the  rec¬ 
tangle  is  its  color,  and  the  value  of  the  dialog  box  is 
defined  as  the  filiered  value  of  the  rectangle. 


requests  the  designer  to  give  an  example  of  the  value  die 
function  would  return. 

Sometimes,  the  value  of  a  widget  might  be  computed  based 
on  the  values  of  multiple  other  widgets.  In  the  example  of 
section  3,  ihe  value  cf  the  Standard  font  radio  buuon 
is  computed  based  on  the  values  of  liuee  sets  of  buttons. 
The  default  expression  creates  a  list  out  of  the  values,  but 
by  editing  the  filter  expression,  it  is  easy  to  create  a  record 
or  structure  instead  of  a  list,  or  to  process  die  values  in 
various  ways.  In  Figure  2-b,  ihc  get -standard-font 
routine  is  called  on  die  values  of  three  widgeis  to  return  a 
single  font  object 

Gilt  allows  decorations  to  be  added  to  the  diait^  boxes, 
such  as  rectangles,  lines  and  labels.  These  normally  do  not 
have  a  value,  but  they  can  be  given  one  using  a  value 
Control  window.  For  example,  the  rectangle  at  the  up¬ 
per  center  of  Figure  5  shows  the  current  selected  color. 
The  value  of  this  rectangle  should  be  its  color.  To  achieve 
this,  the  designer  can  type  (gv  :self  :  COLOR)  uito 
the  filter  Expression  field.^  To  make  this  a  little 
easier,  the  designer  can  choose  die  desired  field  of  the 
selected  object  from  a  pop-up  menu. 

The  user  can  check  that  the  filter  expression  is  achieving 
the  desired  result  in  two  ways.  First,  the  interface  can  be 
exercised  to  test  the  code.  Second,  the  filter 
Expression  field  shows  the  Lisp  code  that  is  being  used. 


^gv  lundt  for  '‘get  value"  and  ■)  looki  in  ilw  ipecificd  object  for  ihe 
ipccified  iloL 
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In  the  future,  we  will  be  investigating  other  techniques  for 
showing  the  transformations  that  will  be  usable  by  non- 
progianuners.  For  example,  the  filter  expressions  might 
use  normal  arithmetic  expressions,  or  we  might  create  a 
special  graphical  programming  language. 

Error  Handling 

Call-back  procedures  in  other  toolkits  are  often  used  to 
check  for  error  values,  especially  in  text  input  Helds.  Gilt 
provides  a  standard  entor-Hltering  mechanism  that  min¬ 
imizes  the  connections  between  the  enor  checking  code 
and  the  widgets.  The  designer  can  bring  up  the  Error 
Check  window  (Figure  3),  and  type  a  value  into  the  i£- 
value-is  field.  If  the  filtered  value  for  the  widget  is 
ever  equal  to  the  i^'-value-is  value,  then  an  error  has 
occuiT^  If  the  Error  String  Held  contains  a  string, 
then  a  error  dialog  box  is  popped-up  showing  that  string. 
The  string  can  embed  references  to  other  widgets  using  the 
Uae-Value-of-Ob ject  button,  for  example,  to  show 
the  incorrect  value.  Alternatively,  if  the  Error  String 
Held  contains  an  expression  or  function  call,  then  it  is  ex¬ 
ecuted. 

Alternatively,  an  expression  using  the  value  of  the  widget 
can  beenier^  into  the  if-valua-is  Held,  which  should 
return  T  if  an  error  should  be  repcmed.  For  example,  to 
repon  an  error  if  an  input  number  is  odd.  the  designer  could 
simply  enter  (oddp  (gv  :sel£ 
:FXLTeREP>VAI.UE)  >.  If  the  filter  expression  itself 
returns  an  error  message  string,  then  the  i£-value-i3 
might  just  test  if  the  filtered  value  is  a  string,  and  the 
Error  String  would  just  be  (gv  :3el£ 

; FILTEREO-VALUE) . 

There  can  be  multiple  i£-value-i3  and  Error 
String  pairs,  which  would  be  useful,  for  example,  for  a 
font  finding  routine  that  returned  different  values  to  tell  if 
the  file  was  not  found,  or  if  the  Hie  was  not  a  valid  font,  as 
in  Figure  3.  The  get-£ont-f rom-file  filter  will 
return  a  font,  or  NIL  if  the  file  is  not  found,  or 
:  NOT -FONT  if  the  file  is  found,  but  it  is  not  a  font. 

43  Preparing  Data  to  be  Shown  to  the  User 
Most  toolkits  require  that  the  designer  create  additional 
procedures  to  sei  the  widgets  based  on  applicauon  specific 
data.  For  example,  when  many  dialog  boxes  are  made 
visible,  the  values  of  some  widgets  should  be  set  to  a  par¬ 
ticular  value.  If  a  widget  should  always  have  the  same 
value  when  the  dialog  box  appears,  then  the  designer  can 
simply  supply  this  value  by  example,  as  in  other  interface 
builders  like  Druid  (121.  However,  it  is  very  common  for 
the  initial  values  for  widgets  to  depend  on  application- 
supplied  data.  For  example,  when  the  font  dialog  box  is 
made  visible  by  an  application,  it  should  reflect  the  font  of 
the  selected  object,  or  if  there  is  no  object  selected,  then  the 
current  global  default  The  next  sections  discuss  how  Gilt 
allows  this  to  be  specified  easily. 
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Figure  6: 

The  Gilt  window  to  cause  the  displayed  value  of  a 
widget  to  change  bated  on  other  widgets.  Here,  die 
Standard  Fonc/Othec  Font  radio  butions  of 
Figwe  1  are  set  bated  on  the  value  of  the  parameter. 
The  designer  only  had  to  select  the  is-a-standard- 
f  on  t  procedure  from  a  menu,  the  rest  of  the  expression 
was  entsed  by  Gilt  as  the  widgets  in  Figure  1  were 
operated.  - 


for  the  parameter.  If  an  application  wants  to  display  a 
window  designed  in  Gilt,  it  can  simply  call^ 

(Show-Dialog  dialot-namtt  parami  poram2  ,  . 

For  example,  the  font  dialog  box  of  Figure  1  would  take  a 
single  font  object  as  a  parameter.  Thus,  the  application 
causes  the  dialog  box  to  appear  while  still  being  independ¬ 
ent  of  bow  the  parameters  are  used  to  set  the  widgets. 

For  ’‘modal’*  dialog  boxes  (that  require  the  user  to  say  OK 
or  CANCEL  before  doing  other  operations),  the 
Show-Dialog  outine  will  return  the  value  of  the  dialog 
box.  The  designer  can  specify  the  value  of  the  dialog  box 
using  a  value  Control  window,  as  was  shown  in  the 
example.  For  non-modal  dialog  boxes,  Show-Dialog 
will  return  immediately,  and  the  designer  can  attach  a  call¬ 
back  procedure  to  the  OK  button.  Of  course,  this  call-back 
will  be  passed  the  filtered  value  of  the  window,  so  it  will  be 
independent  of  the  widgets  that  ait  used  in  the  window  to 
enter  the  value. 

432  Using  the  Parameters 

To  set  the  value  of  a  widget  based  on  the  parameters,  the 
designer  uses  the  Change  my  Value  window  (see 
Figure  6).  The  primary  difference  from  the  Value 
Cont  col  window  shown  earlier  is  (hat  here  we  are  chang¬ 
ing  the  value  shown  to  the  user,  rather  than  simply  filtering 
(he  value  returned  by  the  widget  However,  this  window  is 
very  similar  to  the  value  Control  window,  and  the  in¬ 
terface  to  (he  designer  is  essentially  the  same. 

The  result  of  the  expression  should  be  an  appropriate  value 
for  the  widget.  For  example.  Figure  6  calculates  the  string 


43.1  Defining  Parameters  to  the  Dialog  Box 
When  a  window  is  designed  in  Gilt,  parameters  to  the  win¬ 
dow  can  be  specified,  along  with  an  example  current  value 


*10  (  UngtMfc  Uut  doe*  not  luppott  (unctiora  with  i  vanabic  number  oT 
arfumcma.  a  Gili-Uke  builder  could  create  a  difrcient 
ahow-<dlatoq-n«iii«>  romiiie  for  each  anndow  deiitned. 
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Figure  7: 

This  dialog  box  (which  uses  the  Gsniet  widget  set  in¬ 
stead  of  the  Motif  widget  set  used  by  the  other  figures  in 
this  paper),  repeats  the  chock  box.  the  label  and  the  text 
Q^-in  field.  The  controlling  expression  for  (a)  might 
be((T  :LEFT  jTOP)  <T  :WIDTH  tHEIGHTI), 
where  the  T  controls  the  radio  buiwn.  the  second  ele¬ 
ment  is  used  in  the  label  and  the  third  is  used  as  the 
default  for  the  text  input  field.  The  user  can  then  turn 
on  and  off  the  desired  slots  using  the  check  boxes,  or 
type  a  new  name. 


name  of  the  branch  of  the  radio  button  to  be  sekcied.  Of 
course,  designers  can  simply  type  in  the  appropriate  code, 
but  Gill  provides  demonsiraiional  techniques  to  make  this 
easier.  The  designer  can  operate  the  widgets  to  put  them 
into  the  appropriate  state,  and  then  give  the  expression  that 
will  determine  when  that  state  is  to  be  used.  For  example, 
for  the  font  dialog  box,  the  designer  could  select  the 
Scandard  Fonc/Other  Font  widget,  and  bring  up  a 
Change  my  Value  window  (Figure  6).  Then,  the 
Standard  Font  radio  button  would  be  pressed,  and  the 
designer  could  hit  the  Use  Value  of  Parameter  but¬ 
ton.  Then,  the  designer  would  have  to  edit  the  expression 
to  return  T  when  the  font  was  a  standard  font  using  the 
is-a-standard-font  procedure.  By  default,  the 
other  value  of  the  radio  buttons  will  be  used  otherwise,  so 
nothing  is  needed  for  that  case.  Next,  the  designer  would 
bring  up  Change  my  Value  windows  for  the  other 
widgets,  such  as  Font  Name,  and  write  expressions  to 
extract  the  appropriate  information  from  the  font  object 
parameter. 

4J.3  Dynamic  Creation  of  Widgets 
Sometimes,  a  parameter  might  specify  the  number  of 
widgets  (hat  need  to  be  created.  In  this  case,  the  designer 
can  show  by  example  the  set  of  widgets  to  be  replicated, 
select  them,  and  bring  up  a  Replicate  Control  win¬ 
dow.  which  is  similar  to  the  Change  my  Value  win¬ 


dow.  The  expression  in  this  wintktw  is  expected  to  return 
an  integer  to  tell  how  many  cop^  of  the  widgets  arc 
desired.  Alternatively,  the  expression  out  return  a  list  of 
values,  in  which  case,  the  number  of  copies  depends  on  the 
length  of  the  list  Here,  each  copy  is  assigned  the  ap¬ 
propriate  element  from  the  list  For  example,  in  Figure  7, 
the  application  might  supply  as  a  parvneter  to  the  dialog 
box  a  list  of  slot  names  to  control  how  many  tiroes  the 
check  box,  the  label  and  the  text  input  fteld  are  repeated. 

4.4  Internal  Control 

In  other  toolkits,  another  set  of  call-back  procedures  are 
often  needed  to  control  the  setting  of  the  value  or  other 
propeny  of  one  widget  based  on  me  value  of  another,  or  to 
bring  up  a  new  dialog  box  when  a  bttfton  is  pressed.  The 
next  sectioas  discuss  bow  Gilt  allows  these  to  be  specified 
using  filler  expressions. 

4.4.1  Value  Dependencies 

Sometimes,  when  a  widget  is  operated,  this  should  cause  a 
different  widget  to  change  its  value.  For  example,  when 
the  user  hits  on  a  color  button  in  Figure  S,  the  sliders 
should  move  to  show  the  appropriate  values  for  that  color. 
Gilt  provides  a  convenient  mechanism  for  specifying  this 
using  the  same  Change  my  Value  window  as  for 
having  a  widget’s  value  depend  on  a  parameter  (Figure  6). 

The  designer  selects  the  widget  ihat  should  change  (for 
example,  the  red  slider  of  Figure  S).  and  brings  up  a 
Change  my  Value  window.  Next,  the  widget  that  it 
should  depend  on  (here,  the  color  button  set)  is  selected, 
and  the  Use-value-o£-Object  button  is  hiL  This  will 
generate  the  expression 

(qv  Cotor-buccons  iFILTCREO-VAUIE) 

but  for  the  red  slider,  only  the  red  component  of  the  color 
should  be  used,  so  the  designer  would  edit  the  expression  to 
be 

tqv  Color-buetoni  :FILTEBED-VALUE  ;REDI 

Now,  whenever  the  color  buttons  are  operated,  the  red 
slider  will  be  set  correcily.  The  other  two  sliders  would  be 
fixed  similarly. 

Sometimes,  widgets  may  need  to  be  replicated  based  on  the 
value  of  another  widget  In  the  Xerox  Star  and  Viewpoint, 
menus  only  show  legal  values,  rather  than  greying  out  il¬ 
legal  values.  For  example,  in  a  font-choice  dialog  box,  if 
different  fonts  have  different  sizes  available,  the  com¬ 
ponents  in  the  menu  of  sizes  must  be  dynamically  changed. 
The  Replicate  Control  window  discussed  in  secuon 
4.3.3  IS  used  to  control  this. 

4.42  Specifying  Other  Dependencies 
The  previous  suctions  discussed  how  the  value  of  a  widget 
can  be  controlled.  In  many  cases,  however,  other 
properties  of  widgets  may  need  to  be  set,  such  as  whether  it 
is  enabled  or  not  (greyed-out).  This  is  handled  in  a  uniform 
way,  using  a  window  similar  to  the  change  my  value 
window.  The  designer  selects  the  widget  to  controlled, 
specifies  the  desired  property  from  a  menu,  and  the  ap¬ 
propriate  window  is  brought  up. 
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4.4J.1  Enabling 

One  of  the  most  comm<Mi  dependencies  is  to  enable  widgets 
based  on  other  widgets.  As  shown  in  the  example  of  sec¬ 
tion  3.  the  designer  can  operate  a  widget  to  have  the  ap¬ 
propriate  value,  then  enable  or  disable  the  dependent 
widget,  and  Gilt  will  nil  in  the  values  for  the  Change  ray 
Enable  (Figure  4).  In  trying  to  guess  appropriate  control 
expressions  for  dependent  slots.  Gilt  knows  about  check 
boxes  and  radio  buttons  being  on  or  off.  text  fields  being 
empty  or  having  a  value,  and  numbers  being  zero  or  non¬ 
zero.  In  addition,  if  the  Change  ray  Enable  window  is 
for  a  set  of  selectable  items  (such  as  a  menu  or  a  panel  of 
buttons),  the  controlling  widget  can  reuim  a  list  of  values, 
each  dement  of  which  controls  an  item.  For  example,  in 
Figine  8.  the  menu  of  font  sizes  wUl  have  a  Change  My 
Enable  expression  that  computes  the  list  of  valid  font 
sizes  based  on  the  selected  font  in  the  left  menu.  Although 
an  application  function  is  needed,  the  function  will  be  inde¬ 
pendent  of  the  particular  widgeu  used,  since  it  will  take  a 
font  ob^t  and  return  a  list  of  valid  sizes.  Gilt  will 
automatically  create  an  expression  to  enable  the  items  that 
correspond  to  the  values  in  the  list  and  disable  the  others. 

4.4J1.2  Other  Properties 

All  the  other  properties  of  widgets  can  be  controlled  in  the 
same  way  as  enabling.  Widgets  can  be  made  to  be  visible 
and  invisible  by  bringing  up  a  Change  my  Visible 
window.  Most  widgets  also  have  additional  properties 
which  can  be  set,  such  as  their  color  or  font.  To  change  the 
color  of  an  object,  the  Change  my  Color  window  is 
used.  For  example,  to  change  the  color  of  the  red  slider 
based  on  the  value  it  returm,  the  designer  could  simply 
select  the  red  slider,  bring  up  the  Change  ray  Color 
window,  select  the  slider  again,  hit  the  t}se-Value--of- 
Ob  jecc  button,  and  then  edit  the  expression  to  be^ 

(H*k«-Coior  (qv  :s«lf  : FILTEREO-VXLUE) 

0  01 

Using  the  dependency  control  on  various  properties  is  also 
useful  for  dtxorations  such  as  rectangles  and  labels.  For 
example,  the  color  of  the  rectangle  in  the  center  of  Figure  S 
can  be  made  to  depend  on  the  dircc  sliders  in  this  way. 

4.4.3  Sequencing  of  Dialogs 
Another  common  internal  conuol  action  that  sometimes  re¬ 
quires  call-backs  is  for  a  button  to  cause  another  dialog  box 
to  appear.  Gilt,  like  other  interface  builders,  allows  this  to 
be  demonsuated,  by  simply  operating  the  button,  and 
showing  which  dialog  box  should  appear.  However,  unlike 
other  systems.  Gilt  also  allows  the  initial  values  of  widgets 
in  (he  sub-dialog  to  be  set.  Windows  similar  to  the 
Change  my  ...  windows  appear  that  allow  the  values 
of  the  parameters  to  the  sub-dialog  to  be  specified  based  on 
the  values  of  the  parent  dialog  box.  Gilt  will  automatically 
create  the  code  lo  call  Show-Dialog  in  the  appropriate 
way.  If  the  sub-dialog  is  modal  (which  is  the  usual  case), 
then  ihe  value  of  the  sub-dialog  is  assigned  by  default  as 


’The  tlidcr'i  value  it  t  immber.  bui  need  a  color  ofaieet  for  ihe  color 
propeny.  Hako-Coloc  it  a  uandaid  reuune  that  lakei  luanfaen 
npreMUUMi  ihe  red,  tieea  and  Muc  values  and  reuinn  t  color  obieci. 
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Figure  8: 

In  thaan  Motif-uyle  menus,  ihn  vuioua  font  sizes  in  (be 
menu  on  the  Tight  becotne  enabled  or  disabled  depend¬ 
ing  on  the  sixes  available  for  the  font  that  is  selected  in 
(he  menu  on  the  left. 


the  value  of  the  button  that  caused  the  sub-dialog  to  be 
displayed.  Of  course,  the  designer  can  control  this  using 
thevaluo  Control  forthe butioo. 

If  the  sub-dialog  is  not  modal,  then  the  end  user  will  be 
allowed  to  operate  widgets  in  both  windows.  Gilt  supports 
cross-window  dependencies,  so  that  a  value  in  one  dialog 
box  can  depend  on  a  value  in  aiKMher  dialog  box. 

5.  Editing  and  Saving 

To  edit  the  value  of  any  of  the  filter  expressions  for  a 
widget,  the  designer  can  simply  select  the  widget  and  bring 
up  Ihe  appropriate  Control.  .  .  or  Change  ray.  .  . 
window.  The  designer  can  then  edit  the  text  of  the  expres¬ 
sion.  AlieTnaiively,  if  the  user  demonstrates  new  transfor¬ 
mations,  these  will  replace  the  existing  ones  as  appropriate. 

Gilt  provides  a  special  feature  to  make  it  easier  to  convert 
an  interface  to  a  dirferem  natural  language.  Aficr  a  value 
transformation  has  been  specified,  ihe  next  time  the  desig¬ 
ner  edits  the  displayed  label  names.  Gilt  will  pop-up  a 
question  to  ask  if  the  conesponding  exported  values  should 
change  also.  If  the  designer  says  "no*,  then  the  value  filtei 
function  is  automatically  changed  so  (hat  all  the  new  label 
strings  will  still  produce  the  same  old  values,  so  any  code 
that  uses  the  values  will  not  nrod  to  be  changed. 

Other  special  feauires  make  editing  the  widgets  easier.  Gilt 
provides  a  "Replace  widget”  command,  which  allows,  for 
example,  a  set  of  buttons  to  be  replaced  by  a  menu.  As 
many  of  the  properties  as  possible  are  retained,  including 
the  label  names  and  the  filter  expressions.  In  addition,  the 
filter  expressions  can  be  copied  from  one  widget  to 
another.  Finally,  because  the  more  complex  filter 
procedures  and  ^>plication-specific  call-backs  are  called 
with  abstract  parameters  (such  as  keywords),  they  usually 
will  not  need  to  be  changed  when  the  widgets  are  edited. 
We  will  be  investigating  other  techniques  for  editing  in  the 
future. 
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As  was  meniioned  previousiy,  the  expressions  are  im- 
piemenied  as  constraints  attached  to  the  appcopriate 
properties  of  objects.  Garnet  has  a  built-in  mechanism  for 
saving  any  object  as  a  Li^  code  file,  including  all  of  its 
constraints  [10].  and  this  is  used  by  CilL  Therefore,  all  the 
niter  expressions  are  output  auuWically  along  wiil>  the 
user  int^ace  deHnidon.  Since  the  output  is  textual  Lisp 
code,  it  is  passible  for  pfx>grammen  to  e^i  the  nie  directly, 
but  we  expect  this  to  not  be  necessary. 

6.  New  Kinds  of  Widgets 

The  techniques  that  have  been  described  are  not  limited  to 
only  the  built-in  widgets  in  the  Garnet  toolkits.  If  the  user 
wants  a  new  kind  of  widget,  then  it  can  be  created  cither  by 
coding  it  by  hand  or  using  the  Lapidary  design  tool  (7|. 
The  new  widget  can  then  be  dynamically  loaded  into  the 
Gilt  palette,  and  used  like  any  built-in  widget 

All  of  the  widgets  in  (he  Garnet  toolkit  are  controlled 
through  the  same  protocol,  which  includes  a  speciftcation 
of  what  the  properties  of  the  widget  are  and  the  types  of  the 
properties  (siring,  boolean,  integer,  list  etc.).  This  allows 
the  appropriate  Control  windows  to  be  created.  For  cus¬ 
tom  widgets,  the  designer  will  need  to  conform  to  the  stan¬ 
dard  protocol.  Lapidary  has  built-in  mechanisms  to  help 
with  this  for  widgets  created  using  it  The  infcrencing  of 
the  filter  expressions  is  based  on  the  type  of  the  properties, 
so  the  dcmonstraiional  techniques  dewribed  in  this  papo^ 
can  be  used  for  dcsigncr-creatol  widgets  as  well.  As  an 
example,  the  color  selection  buttons  on  the  left  of  Figure  S 
are  not  a  standard  widget,  but  were  partially  coded  by  hand 
and  then  read  into  Gilt  for  the  dependencies  to  be  speciiied. 

Another  interesting  feature  is  that  a  set  of  widgets  can  be 
saved,  along  with  their  interdependencies  defined  in  Gilt, 
and  used  as  a  prototype  in  other  interfaces.  For  example, 
the  Standard  Font  group  from  Figure  1  could  be  read 
into  the  Gill  palette,  and  then  placed  in  other  dialog  boxes. 
Due  to  the  prototype-instance  object  model  in  Garnet,  no 
extra  mechanisms  arc  needed  in  Gilt  to  suppon  this. 

7.  Status  and  Future  Work 

An  earlier  version  of  Gilt  has  been  released  to  all  Garnet 
users.®  The  version  described  here  has  been  mostly  im¬ 
plemented,  and  is  expected  to  be  finished  and  released  in 
the  next  few  months. 

In  the  future,  in  addition  to  releasing  this  version  of  Gilt  for 
general  use.  we  would  like  to  investigate  combining  some 
of  the  features  of  Lapidary  with  Gilt,  so  that  the  designer 
can  specify  constraints  on  the  widgets,  for  example  to  make 
decorations  or  the  entire  window  grow  if  a  widget  gets 
bigger.  It  has  been  suggested  that  a  wiring  diagram  ap¬ 
proach  to  specifying  the  interdependencies  among  widgets 
might  be  easier  to  use.  We  will  investigate  allowing  the 
designer  to  draw  wims  among  the  widgets  to  show  the  flow 


^IIm  Gtinel  ryucm  it  tvtilabie  for  free  from  CMU,  but  you  need  lo 
tunw  a  lioenic.  If  you  aic  inicraaicd  in  u>in|  Gib  and  Ganrat,  pteaM 
eoniaaiheaMibOToricndeteaionicmailloqarnetgcs.cmu.edu. 
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of  values  and  enabling.  This  might  also  be  helpful  as  a 
debugging  tool  to  show  where  the  dependencies  are.  Other 
debugging  and  maintenance  aids  will  also  be  added,  such 
as  browsers  to  show  ail  the  filter  expressioiui.  atKi  the 
procedures  and  global  variables  used  in  them.  Finally,  we 
will  add  some  of  the  demonsuaiionaJ  techniques  from 
Peridot  and  Druid  that  neaten  the  display  as  widgets  are 
drawn. 

8.  Conclusion 

The  Gill  interface  builder  contains  an  number  of  innova¬ 
tions  that  significantly  improve  the  seperation  of  applica¬ 
tion  code  from  todkiis.  By  identifying  the  most  common 
tasks  that  call-backs  are  used  for.  Gilt  is  aMe  to  siqrply 
built-in  mechanisms  to  handle  them.  Using  a  standard  style 
of  window,  the  designer  can  enter  shon  filter  expressions. 
Because  many  of  the  tasks  involve  straightforward  filler- 
ing.  Gilt  can  often  infer  appropriate  transformations  from 
examples  of  the  desired  output  or  acuons.  Even  when  more 
complex  transformations  are  required,  and  which  use 
application-specific  procedures,  the  application  code  is 
completely  independent  of  the  actual  widgets  and  the 
names  us^  in  the  user  interface.  Although  Gilt  is  im¬ 
plemented  in  Lisp,  which  makes  the  dynamic  execution  of 
the  entered  code  much  easier,  the  general  techniques  are 
appropriate  for  conventional  compiled  languages  and  for 
interface  builden  for  conventional  toolkits.  Therefore,  the 
techniques  could  be  readily  applied  to  today's  user  inter¬ 
face  tools. 

The  mechanisms  that  are  described  here  make  it  much 
faster  to  build  dialog  boxes  with  inierdependencies  among 
the  widgets.  However,  we  expect  their  main  advantage  to 
be  tte  improved  ntainiainability  of  the  resulting  code.  Fw 
example,  it  should  be  much  easier  with  Gilt  than  most  other 
interface  builders  to  convert  a  user  interface  to  a  different 
natural  language  or  switch  between  different  fonns  of 
widgets  (e.g.,  from  menus  to  buttons),  or  even  different 
widget  sets  (e.g.,  from  Motif  to  OpenLxwk).  We  will  be 
exploring  the  effects  of  these  features  as  Gilt  becomes 
widely  used  by  the  Garnet  community. 
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ABSTRACT 

Cooventiaaal  interface  builders  allow  the  user  interface 
designer  to  selea  widgets  such  as  menta.  buttons  sad  scroll 
ban,  and  lay  ibem  out  using  a  mouse.  Although  these  are 
concepaiaUy  simple  to  use,  in  practice  there  are  a  number 
at  ptobtema.  First,  a  typical  widget  will  have  doaens  of 
properties  which  the  desijpier  might  change.  Insuring  that 
iheu  properties  are  consistent  across  multiple  widgets  in  a 
dialog  box  and  multiple  dialog  bores  in  an  apjriicaiion  can 
be  very  diOlculL  Second,  if  the  designer  warns  to  change 
the  properties,  each  widget  must  be  edited  individually. 
Thud,  gettiag  the  widgets  laid  out  appropriately  in  a  dialog 
bos  can  be  tedkais.  Grids  and  alignment  commands  are 
not  suflicieitt.  This  paper  describes  Graphical  Tabs  and 
GraphicalSt/ia  in  the  Gilt  interface  builder  which  solve  all 
of  these  problems.  A  “graphical  tab”  is  an  absolute  posiiioa 
in  a  window.  A  “graphi^  style”  incorporates  both  property 
and  layout  informatian,  and  can  be  defined  by  esample. 
named,  apidied  to  other  widgeu,  edited,  saved  to  a  file,  and 
read  fipcxn  a  file.  If  a  grj^)lucal  style  is  edited,  then  all 
widgea  defined  using  that  ^le  are  modified.  In  addition, 
became  appropriate  styles  are  inferred,  they  do  not  have  to 
be  explic^y  applied. 

KEYWORDS:  User  Interface  Builder.  User  Interface  Man- 
agemem  System,  Demonsuational  Interfaces.  Styles.  Tabs. 
Garnet.  Dim  Manipulation.  Inferencing 

INTRODUCTION 

The  Gilt  Imerface  Builder  allows  dialog  boxes  and  similar 
user  imerface  windows  to  be  created  by  selecting  widgets 
from  a  palette  and  laying  them  out  by  direct  manipulation 
(see  Figure  1).  Two  sets  of  extensions  have  been  added 
to  Gilt  to  mate  it  significantly  easier  to  create  these  user 
iraerfaces.  The  first  set  helps  eliminate  many  of  the  call-back 
procethrret  which  communicate  to  application  programs. 
This  was  described  in  a  previous  paper(8].  The  second  set 
of  extensions  mate  it  easier  and  faster  for  the  designer  to 

PtrmittMn  to  coev  without  too  or  pott  of  ih*i  motoriol  lO 
granted  provulad  that  tha  copiaa  ara  not  mada  or  dia.nbuiad  tor 
diraci  eommaieiU  advantaga.  tha  ACM  copyright  notica  and  tha 
bda  of  tha  publicatron  and  ita  data  appaar.  and  notica  ia  givon 
that  copying  la  by  parmiaaian  of  tha  Aaaocialion  (or  Compuang 
Machinary.  To  copy  otharwiaa.  or  to  rapubliah,  lapuMaa  a  (aa 
and/or  apaeific  pafniaaion. 
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achieve  the  desired  appeannee  for  the  user  imerface,  and  is 
described  here. 

In  most  toolkits,  the  widgets  have  many  propenies  that 
die  designer  can  set.  such  as  the  color,  foot,  label  siring, 
orientation,  size,  the  minimiMn  and  maximum  values  ttf  a 
range,  etc.  Msoy  widgea  in  the  Motif  widget  set.  for 
example,  have  nearly  SO  different  properties  that  can  be  sec 
Most  interface  buiiders,  including  Gilt,  provide  “property 
shee  that  allow  the  designer  to  specify  the  desired  values 
(see  Figure  2).  However,  it  can  be  quite  difficult  and  time 
ccosuming  to  find  and  set  all  of  the  appropriate  propenies. 
To  show  the  magnitude  of  the  problem,  many  applications 
cooiain  over  2000  widgea.  and  the  propenies  for  each  must 
be  set  in  a  consisiem  manner.  A  shidy  has  shown  that 
achieving  consistency  in  an  interface  is  a  frequently  cited 
problem  [9]. 

Another  problem  for  interface  designer  u  laying  out  the 
widgeu  tn  the  window.  When  the  der  .gner  places  widgeo 
with  the  mouse,  they  tend  to  be  urevea  and  look  sloppy. 
Therefore,  most  builders  provide  giids  and  alignmem  com¬ 
mands.  However,  these  can  be  ciuinsy  to  use.  and  they  do 
not  insure  that  different  dialog  boxes  will  have  a  consis- 
tern  aiignmem  (for  example,  that  the  titles  will  always  be 
centered  at  the  top  of  Ur-  wuidow}. 

To  help  solve  Utese  problems.  Gilt  introduces  the  notions  of 
Graphical  Tabs  and  Graphical  Styles.  These  are  based  on 
Uie  styles  and  tabs  in  text  editors  such  as  Microsoft  Word. 
A  “graphical  tab”  is  simply  a  horizontal  or  verucal  posmon 
in  Uie  graphics  window  to  which  objecu  can  be  aligned. 
A  “graplucal  style"  is  a  named  set  of  propenies  and  layout 
infcmiation.  which  can  be  applied  to  widgea.  The  designer 
can  edit  a  widget  so  it  has  the  desired  properties,  select  it, 
and  Uien  define  a  named  style  based  on  it.  The  values  of  the 
propenies  and  die  position  of  the  widgeu  will  be  associated 
with  dut  style  name.  The  style  can  then  be  applied  to  other 
widgeu. 

Fiinhemore.  Gilt  will  try  to  automaticaily  guess  when  to 
apply  •  style,  so  the  designer  does  not  have  to.  By  guessing 
die  appropriate  properties  and  layout.  Gilt  makes  die  user 
imerface  design  process  signifies^  faster,  since  users  can 
quickly  and  imprecisely  place  widgea,  and  the  system  will 
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tutaauuicaUy  aeateo  tbem.  Since  die  infeiaicing  is  based 
OD  the  styles  the  user  has  defined,  rather  than  based  oa 
global,  defoilt  ttties,  at  in  earlier  systems  Idee  Peridot(S}  and 
Dnadllll,  the  Utfemd  piopenies  and  positions  tee  sooce 
likely  10  be  comet. 

A  set  of  styles  and  tabs  can  be  mitten  to  a  file  to  form 
a  Grophieai  StyU  Sh€€t  which  can  be  used  u  intiae  that 
miiltij^  q^iUcations  have  a  consistent  appearanceL  If  a 
styl^  is  edtort.  all  widgets  that  are  baaed  on  that  style  are 
auBwiaticsUy  updated,  so  that  the  interfaces  will  continue  to 
be  consistent 

Gilt  is  a  pan  of  the  Garnet  systemC?].  Garnet  is  a  coinpte* 
henative  user  interface  devekiaient  envarooment  containing 
many  bigb-level  toots,  including  Gilt,  the  Lapidary  inter¬ 
active  design  tooi(6],  and  others.  Garnet  also  contains  a 
cocgtlete  toolkit  which  uses  a  pnxotype-inatanoe  object 
moi^  coostrainis,  and  a  separaikn  of  the  behaviors  fiom 
the  graphics.  Gilt  stands  for  the  Garnet  Interface  Layout 
Tbol.  and  it  supports  interfaces  built  using  diber  the  Garnet 
look-and-feel  widget  set  or  Motif  loak-and-feel  widget  set 
(The  Motif-style  widgets  in  Gsmet  are  impiemenied  on  top 
of  the  Garnet  Toolkit  intrinsics  and  do  not  use  any  of  the  Xik 
code  in  C  Although  (bey  look  tad  behave  like  the  standard 
Madf  widgets,  they  have  the  same  procedural  inierface  as  die 
Gaioet  widget  set)  If  you  are  iatuesud  ia  gettiag  Garnet 
couact  the  second  author.  Gilt  uses  CommooLisp,  but  the 
ideas  presented  here  ate  appiicabiB  to  imerface  builder  ux)ls 
using  convention^  compiled  languages. 

RtLATCOWORK 

Of  course,  there  are  a  large  number  of  commercial  and 
research  interface  builders  ttast  lay  out  widgets,  includ¬ 
ing  the  Piototyper  for  the  Macintosh,  UIMX  for  Motif, 
DialogEdtorfl],  the  NeXT  Interface  Builder(14],  Oniidfl  1} 
and  YUZU{121.  All  of  these  have  the  same  basic  stnicture: 
there  are  two  or  more  windows.  One  is  the  work  window 
where  the  user  interface  is  being  created,  and  another  is  the 
widget  window,  sometimes  called  the  '‘paJeue”  conuining 
the  widgets  that  can  be  placed.  (IVpically,  in  addition  to  the 
standard  interaetkn  techniques  like  menus,  radio  buttons, 
check  boxes,  and  scroll  bars,  there  are  also  decorations  like 
rectaogtes.  lines  and  text  labels  that  can  be  added  to  the 
picture.  In  this  paper,  these  are  all  included  when  the  word 
“widget”  is  used.)  The  designer  selects  a  widget  hom  the 
palette  and  ^aces  it  in  the  work  window  using  a  mouse. 
Usually,  the  tksigner  can  change  the  position  and  size  of 
widgets  using  the  mouse,  and  edit  other  properties  using 
dialog  boxa  or  properly  sheets.  The  builtfers  also  provide 
many  editing  functions  such  as  moving,  copying,  deleting, 
and  aligning  widgms,  and  reading  and  writing  to  a  file. 

Peridot(Sl  guessed  alignment  of  gnqihical  objects  using 
globalrulo.  Dniid(ll]  applies  a  similar  technique  to  widget 
aliguaeoL  When  the  designer  adds  a  new  widget  in  a 
window,  £)niid  inunediately  tries  to  find  other  widgeu  in  the 
window  that  the  new  widget  might  be  aligned  with.  For 
example,  when  the  designer  creates  a  label  below  another 
exiatmg  label,  Oniid  guesses  that  the  new  label  and  the 


Figure  I;  Gilt  Main  Wodows 

Tbe  u>p  is  the  work  window  where  a  dialog  box  for  a  text 
editing  application  is  being  defined.  The  middle  window  is 
the  pateue  of  Garnet  Motif  gadgets  that  can  be  added  to  tlie 
work  window.  The  bottom  window  is  tbe  main  Gilt  controi 
panel  conuining  the  Gilt  emnmaads.  The  position  and  size 
of  the  selected  widget  is  echoed  in  the  text  boxes  at  the  left 
of  this  window. 
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existing  label  should  hsve  the  same  left.  It  pops  up  a  window 
so  tfaedesigner  can  coufinn  the  guess,  and  if  the  designer  says 
yes,  then  Druid  adjusts  the  objects  automaticatly.  However. 
Diuid  does  not  infer  other  properties  of  the  objects,  and  the 
layout  ruin  are  hard-wired,  rather  than  based  on  the  user's 
fnfaeotx,  as  in  Gilt. 


assbownby  the  roMtopfifcrMg  window  at  the  bottom.  The 
suing  "Foot  Selection:”  is  top-justified  on  Row-Tab  A,  and 
centered  horizontally  on  Col-Tab  B,  which  is  centered  in  the 
window,  so  it  will  move  if  the  window  changes  size.  The 
Sryte  Editing  window  (center)  shows  that  the  title  is  using 
Che  style  Main-Title  and  Col-Tab  B  and  Row-Tab  A. 


Many  interface  builders  have  provided  interesting  mecha¬ 
nisms  for  specifying  the  positioas  of  widgets.  For  example, 
FdisisVBTi[2]  and  ibuild  [13]  use  a  “glue”  model  based  on 
TeX.  Glue  has  a  varying  strHch.  and  using  the  right  kinds 
of  glue  between  wi^ets  causes  the  widgets  to  move  ap¬ 
propriately  when  windows  change  size.  In  Lapidary[6],  t^ 
designer  can  select  two  objects,  and  define  arbitrary  layout 
constraints  between  them.  The  most  common  constraiius 
can  be  applied  by  using  iconic  menus.  OPl]S[31  shows 
the  specified  constraints  as  wires  between  the  objects.  We 
feel  that  the  concept  of  tab  stops  will  be  coore  familiar  to 
users  and  will  be  easier  to  use  than  these  other  ^ptoaches, 
whUe  still  {soviding  most  of  the  needed  functionality.  Also, 
no  previous  inieraoive  builder  has  incorporated  a  notion  of 
Graphical  Styles,  as  used  in  Gilt 

The  design  for  styles  and  ubs  in  Gilt  is  based  on  their  use  in 
text  editors,  in  particular  Microst^  Word  for  the  Macituosh. 
Hiis  text  editm  allows  the  users  to  move  a  marker  in  a 
graphical  ruler  to  set  a  ub  stop,  and  if  the  TAB  key  is  typed, 
the  text  cursor  will  move  to  the  designated  place.  To  define 
a  ftyie  in  Nficrosoft  Word,  the  user  formats  some  text  in  the 
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desired  way,  selects  it,  and  then  defines  a  new  named  style 
based  on  ic  More  general  text  styles  are  supported  in  [10], 

GRAPHICAL  TABS 

An  imporuiu  graphic  design  (vinciple  is  that  widgets  should 
be  aligned  evenly.  This  means  that  the  edges  at  centers  of 
the  widgets  should  be  the  same,  and  that  they  should  be 
evenly  spaced.  Funhermore,  dififereni  dialog  boxes  should 
use  the  same  alignments.  For  example,  if  in  one  dialog  box 
a  set  of  radio  buttons  is  left  justified  under  a  uUe,  and  offset 
below  it  by  10  pixels,  the  same  offset  and  alignment  should 
generally  be  used  in  other  dialog  boxes. 

Graphical  ubs  allow  these  kinds  of  relationships  to  be 
defined.  A  “graphical  ub"  is  a  horizontal  or  vertical  posiuon 
in  a  window.  A  hodzontal  ub  position  is  specified  relative  to 
the  top,  bottom  or  center  of  a  window.  Similarly,  a  vertical 
tab  is  specified  relative  to  the  left,  right  or  center.  This  allows 
the  tabs  to  move  appropriately  if  the  window  is  resized.  Just 
as  with  text  editor  ubs.  the  designer  can  specify  whether  the 
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Figure  4:  Style  Editmg  Window  fa  Relative  Positioa 
The  poaition  for  the  radio  buncos  is  defined  relative  to  the 
string  "Size”. 


widgets  will  be  left-justified,  centered,  or  right-justified  on 
the  tab  (or  top-,  centered,  or  bottom-justified  for  horizontal 
tabs).  Since  Gsniet  is  implemented  on  X/11  which  uses  a 
pixel  cooniinate  system,  the  t^Esets  are  ^xcified  in  pixels. 
Gilt  names  the  talM  with  letters  (although  user-named  tabs 
might  be  added  in  the  future).  Figure  3  shows  a  Gilt  work 
window  with  a  set  of  tabs  visible.  Whether  the  tabs  are 
visible  or  not  is  controlled  by  a  command. 

New  tab  stops  can  be  explidtiy  added  by  clicking  on  the 
“add  tab”  buttons  in  the  TabStop  Editing  window  shown  at 
the  bottom  of  Figure  3.  Tabs  can  be  selected  by  pointing  on 
the  label  next  to  the  line  in  the  work  window.  'Ilte  selected 
tab  can  then  be  deleted  if  no  styles  or  widgets  are  using  it 
Tabs  can  be  edited  by  entering  new  values  into  the  tabstop 
editing  window,  or  the  tab  stop  labels  in  the  work  window 
act  as  handles  and  can  be  directly  dragged  with  the  mouse. 
When  a  tab  is  moved,  ail  of  the  widgets  defined  using  that 
tabs  are  also  moved. 

GRAPMCAL  SrrYLES 

A  graphical  style  includes  a  set  of  widget  properties,  and 
optux^y  some  position  information  as  well.  To  create 
a  new  style,  the  designer  modifies  a  widget  to  the  desired 
appearance  using  the  ccmventional  property  sheets,  selects 
that  widget,  and  then  issues  the  Define  Style  command.  The 
designer  must  then  type  a  style  name  into  the  Style  Editing 
window  that  will  appear.  Gilt  compares  the  widget’s  current 
proper^  with  the  default  values  for  that  widget  and  copies 
all  that  are  diCfetem.  The  widgets  used  to  define  the  style  are 
surrounded  with  a  dark  outline  rectangle  in  the  work  window 
while  the  style  is  being  defined  or  edited  ("Font  Selection:” 
in  the  top  window  of  Figine  3). 


Moia-Ticla 

OK  I  Cancel 

1 

,  ,  Sub-Title 

Change  Ref «  re  k  c 

Praps  &  Pos 

traps  CWtiT 

Pos  QKLT 

Figure  3:  Set  Style  Window 

This  window  allows  designers  toexplkiily  set  a  style.  All  the 
current  defined  styles  are  listed  on  the  left,  and  the  designer 
can  choose  one,  and  then  specify  whether  the  associated 
properties,  positioa  or  both  should  be  tpplied  to  the  selected 
widget.  If  the  selected  style  uses  a  relative  positioa  (Figure 
4).  then  the  Change  Referent  button  is  not  grayed-oui,  and 
can  be  used  to  select  the  widget  that  the  widget  should  be 
relative  m. 


Since  all  the  widgets  in  the  Garnet  toolkit  use  the  same  names 
and  values  for  similar  properties,  a  style  defined  on  one  type 
d  wid^  will  erfteo  work  on  other  types.  For  example,  radio 
buttcos,  check  boxes,  and  button  seu  all  allow  the  designer 
to  specify  the  orientation  (horizontal  or  vertical)  and  fonts, 
tn  the  top  window  of  Rgure  1,  all  the  buttons  have  the  same 
style  properties.  The  types  that  styles  are  associated  with 
include  strings,  buttons  (which  include  radio  buttons,  check 
boxes  and  button  seu),  numeric  sliders  (which  include  both 
sliders  and  scroll  bars),  text  input  fields,  etc. 

Styles  can  also  include  position  infotmation.  For  example, 
a  designer  might  specify  that  widgeu  with  the  Main-Title 
style  should  use  a  very  large  bok)  and  italic  font,  and  be 
centered  at  the  top  of  the  window.  The  posititxi  infonnation 
for  styles  can  either  be  with  respect  to  a  graphical  tab  stop, 
or  relative  to  a  previously  created  widget  Fex  the  first  type, 
the  appropriate  ub  name  can  be  entered  into  the  style  editing 
window  (see  the  center  window  of  Figure  3).  Either  or  both 
of  the  bmizontal  and  vertical  tab  name  fields  can  be  blank, 
in  which  case  no  position  information  is  recorded  in  that 
direction. 

Tospecify  that  a  style’s  position  should  be  relative  to  another 
widget,  the  designer  selects  the  referent  widget  after  the  style 
editing  window  is  displayed.  The  style  window  will  then 
change,  as  shown  in  Figure  4.  When  a  style  is  rclmivc, 
only  the  type  of  Uie  referent  widget  is  rcmcinberud.  l  or 
example,  in  Figure  4,  the  style  is  defined  as  offset  from  any 
siring.  This  will  allow  the  Button-Belaw-Label  style  to  be 
used  relative  to  other  strings,  which  can  be  in  other  pans  of 
the  window. 

The  Set  Style  window  (see  Figure  5)  allows  the  designer  to 
choose  any  of  the  defined  sty  les ,  and  also  whether  the  posititxi 
and  properties  aspectt  of  the  style  should  be  applied.  When 
setting  the  properties.  Gilt  checks  each  propetfy  associated 
with  the  style  to  see  whether  the  widget  accepts  that  propeny. 


120 


UIST’92 


Monterey,  California 


103- 


Second  Garnet  Compendium 
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cancal  chan^a 
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StylaKag  lalawfarf  Cbjaati  MKbr-Xttla'  '  : 

Figure  8:  Warning  Window 

Figure  6:  Style  Coatrol  Window  TUs  window  pops  up  when  tbe  designer  edits  a  widget  tlut 

Hiis  window  allows  stylu  to  be  read  and  written  to  a  file,  has  a  style  attached  to  iL 

and  style  guessing  to  be  turned  on  and  off.  Also,  the  style  - 

of  the  selected  widget  is  always  echoed  at  the  bottom  of  the 
window. 


If  not,  then  that  property  is  ignored.  For  example,  a  style 
defined  using  radio  buttons  might  have  a  value  for  the  Text- 
on-l^-p  property,  which  determines  which  side  the  diamond 
is  on.  However,  this  is  not  relevant  for  push  buuons  (since 
their  text  is  inside  the  button),  so  it  would  then  be  ignored. 
For  styles  with  absolute  posititnis,  the  widget  simply  moves 
to  tbe  coirect  tab  stop.  For  relative  positions,  the  user  can 
specify  the  referent  widget. 

INFERRING  STYLES 

Although  the  styles  mechanism  as  described  above  is  already 
quite  useful,  Gilt  goes  further  and  tries  to  automatically 
detennine  when  a  particular  style  is  appropriate.  The  Style 
Control  window  figure  6)  provides  three  options:  no 
infeiencing  of  styles,  styles  applied  inunediaiely  when  they 
axe  inferred,  or  a  prompt-first  mode  where  the  designer 
is  asked  if  the  style  should  be  applied,  as  in  Peridot  and 
Druid.  If  the  system  usually  infers  the  correct  style,  then  (he 
immediate  mode  will  be  the  most  efficient. 

When  infereocing  is  on.  Gilt  tries  to  infer  a  new  style 


whenever  a  widget  is  created  or  moved.  The  algorithm  looks 
for  styles  (hat  affect  tbe  same  type  as  the  widget,  and  checks 
how  close  tbe  widgeimatches  the  style's  position.  For  a  style 
with  a  relative  position,  in  (vder  to  find  its  possible  referent 
widgets  Gilt  checks  all  the  widgets  of  the  appropriate  type 
near  the  new  widget.  A  list  is  aeaied  of  all  tbe  styles  that 
match,  sorted  according  to  the  distance  to  the  tab  stops  or 
the  referent  widgets.  For  example,  in  Figure  1  the  main-title 
and  the  sub-titles  use  different  styles  with  different  foots  and 
positions,  and  Gilt  can  infer  the  appropriaie  style  from  the 
position  when  the  designer  places  the  new  string. 

Any  inferencing  system  will  sometiroes  guess  wrong.  Thus, 
it  is  important  to  provide  appropriate  feedback  so  the  users 
are  confident  that  they  are  in  control  and  know  what  Gilt  is 
doing.  In  immediate  mode,  the  first  style  on  the  style  list  is 
immediately  applied  to  the  widget,  and  tbe  name  of  the  style 
is  shown  at  the  bottom  of  the  style  control  window  (Figure 
6).  The  widget  will  also  jump  to  the  inferred  position  and 
change  appearance.  If  the  inferred  style  is  not  correct,  the 
designer  can  hit  the  Try  Again  button  (Figure  6),  which  will 
remove  the  guessed  style  and  instead  apply  the  next  style  in 
the  sorted  list.  The  Undo  button  can  also  be  hit  to  remove  the 
guessed  style,  and  return  the  widget  to  its  original  position 
and  properties.  In  prompt-first  mode,  the  sorted  list  of  all 
the  inferred  styles  is  presented  in  a  window,  with  the  most 
likely  selected.  Tbe  designer  can  select  a  different  style,  if 
necessary,  and  then  hit  OK  or  Cancel, 


When  a  style  is  defined,  it  immediately  becomes  a  candidate 
for  inferencing.  This  is  very  usefiil  when  a  number  of 
widgets  will  all  be  created  using  the  same  style,  in  Figure  7, 
after  the  designer  defines  a  style  which  centers  tbe  text  label 
below  the  first  saoll  bar.  when  the  second  scroll  bar  and  label 
arc  created,  the  label  will  automatically  be  centered.  This 
highlights  an  advantage  of  tbe  style  approach  over  a  rule- 
based  approach  as  used  in  Druid  and  Peridot  Those  systems 
might  have  put  tbe  label  left-justified  under  tbe  second  scroll 
bar  if  it  was  placed  closer  to  that  alignmem.  but  Gilt  only 
matches  against  previously  demonstrated  styles,  so  it  is  more 
likely  to  guess  the  designer’s  inteniioas.  This  will  also  help 
achieve  a  consistent  design. 
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EOnWQ  STYLES 

When  a  style  is  applied  to  a  widget,  either  explicitly  or 
iofemd.  Gilt  sets  up  appropriate  pointeni  and  back  pointers 
SO  that  if  the  style  is  ever  edited,  all  widgeu  using  that  style 
are  iinaaediately  iipdated. 

Styles  can  be  edited  in  two  ways.  A  propeny  sheet  can  be 
di^ilayed  which  shows  the  current  values  of  the  properties 
for  die  style,  and  this  can  be  edited  directly.  This  property 
sheet  has  the  same  format  as  the  ones  for  the  standard  widgets 
(Figure  2).  The  position  associated  with  the  style  can  be 
edited  using  the  appropriate  dialog  boxes  (Figure  3  and  4). 

Atternativdy,  the  deagner  can  edit  the  styles  in  the  same 
way  as  they  were  created:  by  working  on  example  widgets. 
Whenever  a  widget  is  edited  that  has  already  been  defined  to 
be  of  a  particular  style.  Gilt  pops  up  a  dialog  box  asking  if 
the  edit  should  change  the  style  itself  (Figure  8).  The  other 
alternatives  are  to  make  the  widget  no  longer  belong  to  the 
style,  or  to  cancel  the  change  and  return  the  widget  to  its 
appearance  before  the  edit  was  attempted. 

In  the  future,  we  plan  to  add  the  ability  to  have  widgets 
use  a  paiticuiar  style  with  exceptions,  but  this  is  a  complex 
probiem(41.  Some  of  the  issues  are  whether  to  copy  the 
attributes  or  retain  the  link  to  the  original  style,  what  to  do 
to  a  style  when  the  style  it  inherits  firaic  is  changed,  and 
whether  to  save  the  inheritance  links  in  the  style  files,  or 
write  out  all  the  style  infonnation  to  each  file. 

WnTINQ  AND  REAOINa  STYLES 
A  set  of  styles  can  be  written  to  a  file  using  the  buttons  in 
the  style  comrol  window  (Figure  6).  This  file  can  then  act 
as  a  ‘^tyle  Sheet.”  Whenever  a  new  dialog  box  is  being 
created,  the  style  sheet  file  can  first  be  read.  Then,  the 
ai^xopriaie  styles  can  be  inferred  or  explicitly  applied  to 
ite  widgets.  This  will  help  insure  that  the  new  dialog  box 
is  consistent  with  previous  dialog  boxes  created  for  this  or 
other  applications. 

When  the  work  window  is  saved  to  a  file.  Gilt  will  optionally 
include  the  style  infonnatitm  in  that  file.  In  this  case,  the  file 
is  self-contained.  Alternatively,  the  file  can  simply  contain 
a  pmnter  to  the  apfnopriaie  style  file.  Then,  whenever  the 
window  is  used  by  apjfiications  or  read  back  into  Gilt,  the 
style  file  will  be  re-read,  so  any  subsequent  edits  to  the  styles 
will  be  reflected.  However,  this  can  cause  the  window  to 
look  ugly  (for  example,  if  the  style  for  a  set  of  radio  buttons 
changes  from  horizontal  to  vertical,  the  buuons  are  likely  to 
overlap  other  widgets).  Therefore,  a  veision  tuunber  is  kept 
in  the  style  file,  so  at  least  a  warning  can  be  issued  when  an 
old  window'  is  opened  with  an  edited  style  file. 


EVALUATION 

As  a  small,  informal  experiment  to  see  how  quickly  users 
could  aeate  interfaces,  using  grapical  styles  and  ubs.  four 
subjects  were  given  two  tasks.  E4ch  task  has  two  simitar 
dialog  boxes.  For  the  fint  box  in  each  task  (i.e.OBoxl  and 
DBox3).  the  properties  for  all  widgets  were  set  using  the 


Dialog  Boxes  for  Taskl : 


Dialog  Boxes  for  Task2: 


Figure  9;  Dialog  Boxes  for  Taskl  and  Task2 
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property  stMcts.  Tbeirpositioos  were  detennioed  using  tabs. 

several  styles  were  defined  using  these  prq)erties  and 
posituns.  For  die  second  box  in  each  task  (Le.DBox2  and 
DBox4).  the  properties  and  positions  for  all  widgets  can  be 
infieired  auiomaficaUy,  using  the  styles  defined  in  the  first 
box  (Tabic  1.  Figure  9).  The  same  four  dialog  boxes  are 
created  withom  any  styles  by  a  Gilt  expert.  Tberesulu  were 
used  to  compare  with  above  results  (Table  2  and  3). 


Table  1:  Task  Description 


Taskl 

1  Task2 

DBoxl 

OBox3 

DBox4 

Widgets 

8 

9 

7 

11 

Defined  TibStops 

3 

■K] 

1 

0 

Defined  Styles 

6 

IHEl 

4 

HHEI 

Guessed  Widgets 

2 

9 

3 

11 

From  Table  2  and  3.  it  is  clear  that  the  dialog  box.  where 
all  widgets  ate  inferred,  is  created  in  less  than  half  the  time 
for  diak)'^  boxes  without  styles:  a  0.43  ratio  for  DBox2  and 
a  0.42  i-atk)  for  DBox4.  In  guessing  the  styles  for  users 
on  DBox2  and  DBox4,  Gilt  guessed  correctly  almost  all  the 
tune.  The  over-beads  for  defining  styles  and  tabs  ate  small: 
a  1.73  ratio  for  DBoxl  and  a  1J18  ratio  for  DBox3.  Note, 
however,  that  the  longer  time  for  DBoxl  is  mostly  due  to 
the  leaniing  time  since  this  was  die  first  time  using  Gilt  and 
styles  for  almost  all  subjects.  In  addiaon.  novices  can  team 
Gilt  styles  and  tabs  quickly,  hncaiisc,  in  DBox  1 .  they  needed 
a  1.73  ratio,  but,  in  DBox3,  they  needed  only  a  1.28  ratio. 

The  verbal  protocols  for  these  subjects  indicated  that  they 
felt  that  Gill  style  guessing  was  useful  and  coinforubte. 
Two  subjects  said  that  the  “Try  Again”  button  is  very  good. 
Subject  A,  who  took  this  test  twice,  using  styles  and  without 
ai^  styles,  felt  that  defining  relative  styles  was  very  useful, 
because  tl»  conventional  layout  mechanism  did  not  support 
“offset”  among  widgets,  so  he  often  had  to  calculate  “left 
+  width  *  offset"  values  for  the  referem  widget,  in  order 
to  determine  the  left  band  position  for  the  new  widget.  He 
indicated  that  graphical  ubs  were  good  for  aligning  some 
wuigets  at  particular  fixed  lines.  However,  ail  subjects 
claimed  that  they  had  to  think  about  style  names,  whenever 
defining  iuiy  styles.  They  indicated  that  it  was  difficult 
to  give  good  names  for  ail  styles.  Also,  they  said  that 
somethnes  they  couldn't  remember  whether  this  name  had 
already  been  used  or  not  Thus,  we  plan  to  prepare  a  default 
style  name  in  the  style  editing  window. 

STATUS  AND  FUTURE  WORK 

An  earlier  version  of  Gill  has  been  released  to  all  Garnet 
users.  The  version  described  here  has  been  mostly  imple¬ 
mented,  and  is  expected  to  be  debugged  and  released  in  (he 
next  few  memths. 

In  the  hiture,  we  plan  to  investigate  unifying  labs  with  the 


Table  2:  Taskl  Results 


[sec] 

DBoxl 

OBox2 

DBoxI-t-2 

Style:  Subject  A 

420 

160 

580 

Style:  Subject  B 

1000 

200 

1200 

Style:  Subject  C 

910 

300 

1210 

Style:  Subject  D 

1060 

270 

1330 

Style:  Average 

847 

233 

1080 

No  Style:  Subject  A 

490 

510 

1000 

Ratio 

1.73 

0.45 

1.08 

Table  3:  Task2  Results 


(sec) 

DBox3 

DBox4 

DBox344 

iiiiniiiiii  II M 

250 

no 

360 

Style:  Subject  B 

400 

300 

700 

Style:  Subject  C 

380 

180 

560 

Style:  Subject  D 

500 

180 

680 

Style:  A-erage 

383 

193 

575 

No  Style:  StdrjeaA 

300 

460 

760 

Ratio 

1.28 

0.42 

0.76 

relative  styles.  It  seems  like  (here  should  be  a  convenient 
way  to  define  “relative  ubs”  that  wiU  achieve  the  desired 
results.  As  discussed  above,  we  would  also  like  to  investigate 
exertions  to  the  styles.  There  might  be  a  way  (o  copy  just 
some  values  from  one  style  into  another,  and  ways  to  read 
just  a  few  styles  from  a  file.  Further  work  is  needed  on  ways 
for  the  system  to  automatically  generalize  styles,  so  that,  for 
example,  the  font  propeny  or  color  defined  on  a  radio  buuon 
will  be  applied  to  a  circular  gauge,  even  though  they  have 
different  t:^s. 

s, 

CONCLUSIONS 

The  Graphical  Styles  mechanism  described  in  this  paper 
can  help  designers  more  quickly  create  user  interfaces,  be¬ 
cause  many  of  the  properties  and  alignments  can  be  applied 
with  a  single  specification,  or  even  infeaed  automatically. 
In  addition,  the  styles  can  help  insure  consistency  across 
multiple  dialog  boxes  in  an  application,  and  even  across 
multiple  applications,  since  Style  Sheets  can  be  developed 
and  re-used.  The  Graphical  Tab  mechanism  seems  to  be 
an  easier-to-understand  and  easier-to-edit  mechanism  than 
other  layout  approaches.  Finally,  in  addition  to  being  useful 
for  user  interface  builders,  such  as  Gilt  and  YUZU,  we  feel 
that  the  graphical  styles  and  graphical  ub  mechanisms  would 
be  useful  for  a  wide  range  of  graphical  editors,  including 
drawing  programs  aiKf  CAD/CAM. 
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ABSTRACT 

Many  inodeni  user  interface  development  environments 
use  constraiiuz  to  connect  graphical  objects.  Consoainis 
are  relationships  that  are  declared  once  and  then  maintained 
by  the  system.  Often,  systems  (vovide  graphical,  iconic,  or 
demonstiatioaal  techniques  for  specifying  some  coi- 
straiius,  but  these  are  incapable  of  expressing  all  desired 
relabonships,  and  it  is  always  necessary  to  allow  the  user 
interture  designer  to  write  code  to  specify  cimplex  con- 
steainis.  The  spreadsheet  interfacre  described  here,  called 
C32,  provides  the  programmer  with  the  full  power  of  writ¬ 
ing  constraint  code  in  the  underlying  programining  lan¬ 
guage,  but  it  is  significantly  easier  to  use.  Unlike  other 
spteadsheeu  tools  for  graphics,  C32  automatically 
generates  appropriate  objea  references  from  mouse  clicks 
in  graphics  windows  and  uses  inferencing  and  demonstra- 
lional  techniques  u>  make  constructing  and  copying  con¬ 
straints  easier.  In  addition,  C32  also  suppons  monitoring 
and  debugging  interfaces  by  watching  values  in  the  spread¬ 
sheet  while  the  user  interface  is  tunning. 

KEYWORDS:  Constraints,  Spreadsheets.  User  Interface 
Development  Tools. 

INTROOUCnON 

C32  is  a  tool  that  helps  usen  construct  constraints.  A 
’constraint'’  is  a  relationship  among  objects  that  is 
declared  once  and  maintained  automatically  by  the  system. 
Typically,  a  constraint  is  expressed  as  an  expression  (or 
"  formula”)  that  is  stored  in  a  slot  of  an  object.  The  ex¬ 
pression  is  re-evaluated  whenever  any  other  values  change 
that  are  referenced  in  the  formula.  Constraints  are  used  to 
control  the  graphical  objects  in  many  modem  user  interface 
toolkits. 

C32  uses  a  spreadsheet  model  and  provides  the  program¬ 
mer  with  the  full  power  of  writing  constraint  code  in  the 
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underlying  pmgrainiiiing  Lmgtugc.  Ikiwcvcr.  ii  is  .iig 
nificanily  easier  lo  use,  and  provides  many  of  die  ad¬ 
vantages  for  graphics  jirogramming  that  rmanciai  spread¬ 
sheets  provide  for  business. 

(232  is  different  from  previous  spreadsheet  systems  for  user 
interface  construction  because  it  uses  a  wide  array  of  visual 
and  inferencing  techniques  so  the  user  does  not  have  to 
write  the  enure  constraint  by  hand.  In  particular 

•  (232  automatically  generates  appropriate  references  lo 
^aphical  objects  when  the  user  clicks  on  the  object  in  a 
user  interface  window. 

•  It  uses  demonsuaiional  techniques  to  guess  which 
properties  of  objects  should  be  used, 

•  It  guesses  how  to  parameterize  constraints  when  they  are 
copied  from  one  place  to  another  or  generalized  into 
procedures,  so  abstract  and  reusable  constraints  can  be 
constructed  by  esamplc. 

•  It  incorporates  graphical  techniques  to  help  uace  and 
debug  constraints. 

•  U  is  integrated  with  an  existing  prototype-instance  sys¬ 
tem  ui  which  constraints  can  be  inhenicd. 

•  It  is  one  of  a  suite  of  lools  built  on  top  of  an  exisung, 
successful  consuaint  system,  rather  than  providing  the 
only  interface  to  the  constraints,  so  users  can  choose 
other  tools  when  they  are  more  app  7pnate. 

Many  systems  provide  a  graphical,  direct  manipulation 
technique  for  specifying  some  constraints.  Unfortunately, 
such  techniques  are  incapable  of  expressing  every  con¬ 
straint  the  user  may  want  C32  provides  a  convenient  and 
easy-to-use  technique  for  constructing  constraints  when  the 
graphical  techniques  are  inappropnatc.  For  example,  C32 
pops  up  when  the  user  asks  for  a  custom  constraint  :n  the 
Lapidai7  inicracuve  design  tool  [8).  C32  can  also  be  used 
stand-alone  when  a  graphical  front  end  is  not  available. 
We  have  found  C32  to  be  significanily  easier  to  use  than 
construcung  the  constraints  by  typing  in  code. 

C32  has  been  implcmcnied  as  pan  of  the  Garnet  system 
(10).  It  is  an  acronym,  and  siands  for  CMU’s  Clever  and 
Compelling  Contribution  lo  Computer  Science  m 
CommonLisp  which  is  Customizable  and  Chaiactenzed  by 
a  Complete  Coverage  of  Code  and  Contains  a  Cornucopia 
of  Creative  Constructs,  because  it  Can  Create  Complex, 
Correct  Constraints  that  are  Constructed  Gcarly  and 
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Coocmely.  and  are  Cooununicated  using  Columns  of  Cells 
that  are  Conswitiy  Calciilaied  so"  they  Change 
Continuously' nd  Can^  €»fttsiaa. 

RELATED  WORK 

Spreadsheets  have  beea  used  for  financial  calculations  for  a 
long  time,  staniag  with  VisiCalc  in  about  1984,  and  most 
sysrems  Ime  the  same  fbnn:  an  anay  of  cells,  with  each 
coluna  labeled  with  a  letter  and  each  row  with  a  number. 
Some  eaiensiona  to  the  spreadsheet  idea  include  using  it  for 
logic  programming  {12}  and  a  technique  for  adding 
proced^  abstraction  [!}. 

The  NtdhimpG  and  NoPumpn  systems  [15]  use  spread- 
sheett  to  define  graphical  user  interfaces,  but  they  have  a 
number  of  important  differeaces  from  C32.  The  most  im¬ 
portant  is  that  the  NoPump  systems  provide  many  different 
typer  of  ceils.  In  C32,  all  the  cells  are  the  same  type:  slots 
of  objects.  To  program  the  user  interfrce,  NoPump 
provit^  special  cell  types  that  reported  low-level  mouse 
positions  a^  clock  ticks,  whereas  C32  uses  Garnet’s  high- 
level  Inieractor  objects  [9]  to  handle  behaviors,  and  slots  of 
Inteiaciots  cat  be  qtedfied  and  viewed  in  C32  cells,  just 
like  any  other  object  In  NoPump,  the  cells  are  free  fly¬ 
ing  whereas  C32  uses  a  tabular  organizauoo,  like  a  conven¬ 
tional  spreadsheet.  Thus,  all  the  cells  about  a  particular 
objea  are  always  in  one  place  in  C32.  There  are  additional 
small  differences.  The  cells  in  NoPump  are  typed  and  the 
fdtnuilaa  use  a  spwial  language.  In  C32  the  cells  can  hold 
any  kind  of  value,  and  formulas  are  expressed  in  a  standard 
langu^  (Conunan  Lisp).  Also,  NoPump  provides  few 
facilities  for  object  referencing,  and  none  for  formula 
generalization. 

Consoaints  have  been  used  by  many  systems,  starting  with 
Sketchpad  [13]  and  Tlunglab[3].  Uses  of  constraints 
within  user  interface  loolUts  include  GROW  [2],  Peridot 
[7],  Apogee  (5],  and  CONSTRAINT  [14]. 

Grq>hical  imerfues  to  constraints  include  the  ’’wiring 
diagrams”  in  Thinglab[41,  the  iconic  interfaces  in  Juno 
and  L^idary  [8],  and  the  reference  lines  in  Apogee  [6], 
The  Peridot  system  auiomaticaliy  infers  constraints  from 
example  drawings  [7],  The  wiring  diagrams  are  hard  to  use 
for  cmnplicated  constraints,  and  the  (^er  techniques  can¬ 
not  even  handle  complex  constraints.  The  spreadsheet  in¬ 
terface  described  here  could  be  used  as  a  supplement  to 
these  other  techniques  when  they  cannot  generate  the 
desired  relationship. 

CONSTRAINT  EXPRESSIONS 

Objects  in  Garnet  have  instance  variables  or  fields,  called 
slots.  The  content  of  each  slot  is  either  a  normal  value, 
such  as  a  number  or  string,  or  a  formula  that  computes  the 
value.  References  to  other  objects  in  formulas  use  a  special 
form:  (gv  other-object  slot -name ),  where  gv 
stands  for  “get  value.” 

Because  each  slot  can  contain  at  most  one  formula,  only 
one-tlirectional  constraints  are  supported.  We  are  explor¬ 
ing  multi-way  constraints  for  the  fuUnre,  in  which  case  C32 
will  be  chan^  appropriately. 


Through  extensive  experience  with  the  many  projects  that 
have  hand-coded  Garnet  constnunts,  we  have  discovered 
that  people  have  trouble  generating  correa  constraints.  Al¬ 
though  most  cQOSiraims  in  interfaces  are  very  simple,  there 
are  a  reasonable  number  of  five  to  ten  line  code  ^gments 
used  as  constraints.  Even  the  simple  constraints  can  be 
tricky  to  enter,  since  the  user  must  reference  the  ap¬ 
propriate  objects  and  slots.  Also,  given  a  set  of  constraints 
that  are  not  working  conectly.  users  have  difficuity  finding 
the  bugs.  C32  was  designed  to  address  these  problems. 

OVERVIEW 

C32  can  display  and  allow  the  user  to  edit  any  kind  of 
object  and  constraint,  no  matter  how  they  were  created:  by 
hand-coding,  by  using  Lapidary  (a  Garnet  interactive 
design  tool),  or  by  using  C32. 

Figure  1  shows  a  typical  instance  of  C32.  Each  column 
contains  a  sqiaraie  object  Rows  are  labeled  with  the 
names  of  the  slots,  such  as  : left,  :top,  rwldth, 

: height,  :  visible,  cic.‘  Since  (Jifreiem  objects  can 
have  different  slots,  the  slot  names  are  repeated  in  each 
column.  For  example,  lines  have  slots  for  the  endpoints 
(:xl,  :yl,  :x2,  : y2}  but  rectangles  do  tx>t.  Also, 
each  object’s  display  can  be  scrolled  separately,  so  each 
has  its  own  scroll  tw.  This  makes  the  spreadsheet  look 
somewhat  like  a  multi-pane  browser  as  in  Smalltalk. 

The  spreadsheet  cells  show  the  current  values  of  the  slots. 
If  a  value  changes,  then  the  display  will  be  immediately 
updated.  It  is  imponant  to  emphasize  that  the  user  interface 
being  constructed  will  operate  normally  (albeit  a  little 
slower)  even  while  the  spreadsheet  is  displaying  objects  in 
that  user  interface.  The  underlying  constraint  mechanism  is 
used  iniemally  by  the  spreads^!  to  maintain  this  connec¬ 
tion.  Monitoring  the  values  as  they  change  can  help  the 
programmer  debug  objects,  and  makes  the  constraints 
much  more  “visible”  and  understandable.  If  the  user  edits 
the  value  in  the  spreadsheet  cell,  the  object's  slot  will  be 
updated. 

The  9  icon  by  some  slots  in  Figure  I  means  that  the  slot 
value  is  computed  from  a  formula.  Pressing  the  mouse  on 
the  icon  causes  the  constraint  expression  to  appear  in  a 
different  window  (see  Figure  2).  The  expression  itself  can 
be  edited  by  typing  or  other  uxhniqucs  (discussed  later). 
Note  that  unliim  cells  in  conventional  financial  spread¬ 
sheets,  C32  allows  a  slot  to  have  a  value  different  from 
what  (he  formula  would  calculate.  Therefore,  the  user  can 
edit  the  value  of  slots  with  formulas  without  affecting 
whether  there  is  a  formula  there  or  not  This  can  be  useful 
when  trying  to  find  the  correct  value  for  a  slot  while  debug¬ 
ging.  To  remove  a  formula,  the  user  simply  deletes  the 
entire  string  in  the  formula  display  window. 

One  novel  feature  of  the  underlying  object  system  is  that 
new  slots  can  be  added  to  objects  at  any  time.  Using  C32, 
the  user  can  create  a  new  slot  by  simply  typing  a  slot  name 
and  value  into  a  blank  row. 


'All  liM  lamct  lun  with  *  colon. 
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figure  I:  (a)  C32  viewing  tbne  objects  (b).  The  scroll  bars  can  be  used  to  see  more  slots  or  columns.  Changing  the 
window’s  size  will  change  the  number  of  slots  and  objects  displayed  (the  number  of  rows  and  columns).  Field 
values  are  clipped  if  they  are  too  long,  but  can  be  scrolled  using  editing  commands.  The  O  icon  means  that  the 
slot  value  is  computed  with  a  formula.  All  inherited  slots  are  shown  in  italics  and  marked  with  the  S)  icon, 
(biheritaoce  is  disaissed  in  a  later  section.)  When  e  formula  is  inherited  the  value  is  shown  in  a  regular  font  since 
it  is  usually  diflerem  from  the  prototype’s.  The  inh^ted  icon  is  also  shown  next  to  the  formula  icon  rather  than 
next  to  the  value. 


roiauia  foi  smoni, 

(*  (dv  n-neauax  um 

(nLooB  (-  (8v  ir-uimiKU  ;Viinii} 

(cv  :snjr  wiDn)) 

1  2» 

Figure  2:  A  fcmnula  window  showing  the  constraint  in  the 
:  left  slot  of  the  STRINGl  object  of  Figure  1, 
which  centers  the  string  in  the  rectangle. 


To  view  an  object  in  the  spreadsheet,  the  user  can  simply 
type  the  object’s  name  into  the  title  of  a  column.  Alter¬ 
natively,  the  user  can  select  a  column,  and  then  point  to  an 
object  in  a  graphics  window. 

As  with  financial  spreadsheets  such  as  Microsoft  Excel,  we 
ivovide  a  menu  of  the  common  functioas  used  in 
formulas.^  Another  menu  contains  the  graphical  com¬ 
mands  provided  by  Garnet,  including  functions  to  center 
objects  with  respea  to  other  objects  and  to  make  their  size 


^Tham  tn  m  auny  fnwiiom  m  Commoa  Lup  (bar  only  ih*  men 
oonwonly  <ued  an  pmvidad  ia  the  nenu. 


be  proportional.  The  user  can  easily  add  commands  to  this 
menu,  either  written  in  a  conventional  way  or  created  from 
formulas.  When  functions  are  inserted  from  the  menus. 
C32  puts  the  parentheses  in  the  correct  places  and  leaves 
the  cursor  where  the  arguments  to  the  function  go.  In  this 
way.  C32  can  be  used  like  a  syntax-directed  editor,  which 
has  the  following  advantages; 

•  the  user  does  not  have  to  deal  with  the  syntax  of  the 
language  so  there  will  be  fewer  syntax  errors, 

•  the  system  will  handle  the  parenthesis  matching,  which 
otherwise  can  be  annoying  in  Lisp,  and 

•  this  makes  the  system  accessible  for  people  who  do  not 
know  Lisp. 

GENERATING  OBJECT  REFERENCES 
One  of  the  most  interesting  aspects  of  C32  is  the  way  that 
object  references  can  be  specified.  As  in  a  financial 
spreadsheet,  the  user  c^n  point  to  a  slot  and  have  a  refer¬ 
ence  U)  that  slot  inserted  into  the  formula  at  the  current 
point  Figure  3  shows  how  this  can  be  used. 

In  Garnet,  there  are  different  ways  to  reference  an  object  in 
a  formula.  Unlike  other  systems  such  as  Peridot  and  con¬ 
ventional  spreadsheets.  Garnet  allows  indirect  references  to 
objects,  where  the  object  to  be  referenced  is  stored  in  a  slot 
of  the  object  that  contains  the  formula.  One  place  this  is 
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loed  is  ia  composiiB  objects.  For  example,  if  a  graphical 
aggnsgaie  is  composed  of  a  shadow,  ao  outline  reciangie, 
and  a  Udiei,  as  siiown  in  Bguie  4.  then  a  reference  to  the 
left  of  the  shadow  ftom  the  labd  would  not  name  the 
shadow  directly.  Instead,  the  reference  would  be: 

{<rv-inUlr«ec  :p4r«nC  :sh«<lo<i  :t«fc) 

These  indirea  references  madre  it  much  more  efficient  to 
aeaiB  copies  and  instances  of  aggregates,  since  it  is  rtot 
necessary  to  search  through  all  the  fonnulas  and  change  the 
references  to  refer  to  the  new  objects.  When  the  formula 
and  the  slot  being  referenced  are  part  of  the  same  aggregate 
structure,  then  an  indirea  reference  like  the  one  described 
above  must  be  generated.  If  the  objects  are  totally  distinct, 
then  a  direa  reference  can  be  used.  C32  searctws  the  ob- 
jea  hierarchy  to  decide  which  is  appropriate. 

USE  OF  INFERENCINQ 

It  is  sometinies  not  convenient  to  read  an  objea  into  a 
spreadslwet  column  just  to  generate  a  reference  to  it. 
Therefore,  a  command  will  cause  the  system  to  go  into  a 
mode  where  a  graphical  objea  in  any  Gama  window  can 
be  selected  and  a  reference  to  it  placed  into  the  currem 
formula.  Howeva,  selecting  a  graphical  object  does  not 
specify  which  slot  of  the  objea  should  be  referenced.  In 
one  mode,  the  user  must  type  this  directly  or  selea  a  slot 
from  a  menu.  However,  there  are  two  itiferencing  modes 
that  try  to  guess  the  slot  ftom  the  user’s  actions.  One  uses 
the  current  relationship  of  the  two  graphkal  objects  to 
guess  the  desired  constraint,  much  like  Peridot  [T].  For 
example,  if  the  slot  being  e^ted  is  :  l«£t  and  the  objea 
seems  to  be  centered  horixontally  with  respea  to  the 
selected  object,  then  C32  generates  a  centering  consitainL 

The  other  mode  ignores  the  current  positions  of  the  objects, 
but  looks  at  the  slot  being  filled  and  where  the  mouse  is 
pressed  in  the  selected  object  For  example,  if  the  slot  is 
:  left,  and  the  mouse  is  pressed  at  the  right  of  an  object 
then  the  reference  will  be  to  the  right  of  the  object  For  the 
:  width  slot  however,  the  same  press  would  generate  a 
reference  to  the  width  of  the  object  Unlike  Peridot  C32 
does  not  try  to  confirm  any  of  the  inferences,  but  rather 
simply  inserts  the  text  into  the  formula.  If  the  guess  is 
incorrect  it  is  easy  for  the  usa  to  delete  the  text  and  type 
the  conection. 

Once  a  complex  formula  is  created,  it  will  often  be  needed 
in  a  slightly  different  form  for  a  different  slot  or  a  different 
objecL  As  an  example,  suppose  the  user  has  constructed  a 
constraint  that  centers  an  object  hmizonially  with  respect  to 
two  other  objects  (see  Figure  S).  Now,  suppose  the 
programma  wants  to  centa  the  object  vertically  also.  The 
formula  could  be  copied  to  the  :  cop  slot,  but  all  the  slots 
references  need  to  be  changed  (:Ie£c  to  :top  and 
:  width  to  :  height).  Therefore,  when  a  foimula  is 
copied,  C32  tries  to  guess  whether  some  slot  names  should 
be  changed.  This  uses  a  few  straightforward  rules  based  on 
the  slot  names  of  the  source  and  destination  slots.  If  it 


Figures;  The  spreadsheet  before  and  after  the  user  has 
select^  the  :  top  cell  of  Hy-RECTANGLE  to 
be  inserted  inU)  the  formula. 


Figure  4;  A  graphical  button  and  its  aggregate  hierarchy. 

References  from  one  reject  to  another  use  paths 
through  the  hierarchy.  Objects  that  are  part  of 
the  button  have  programmer-assigned  name*:, 
like  ; shadow  and  : outline,  and  references 
to  the  buticm  from  its  parts  uses  the  standard 
:  parent  slot.  In  a  slot  of  the  shadow,  a  refer¬ 
ence  to  the  :  width  of  the  text  label  would  be 
(gv-indicect  -.parent  -.label 
rwidth) . 
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(b) 

Fignre  5:  (a)  Reciangk  R3  is  centend  hocizonully  between  R1  and  R2  using  the  formula  shown  in  (b)  so  R3  moves 
automatically  when  Rl  and/or  R2  moves. 


that  slot  names  should  be  changed,  the  user  is 
queried  with  a  dialog  boa,  and  if  the  answer  is  OK.  then  the 
formula  is  modified  automatically.^ 

AUTOMATIC  OENERAUZATION 
Another  poss&ility  is  that  the  references  in  the  formula 
should  be  gauratiied  into  variables.  C32  therefore 
provides  a  command  that  will  change  the  entire  formula 
into  a  finctiaa  that  takes  the  objects  and/or  slots  as 
parameters.  This  proem  is  controlled  by  a  dialog  box.  As 
an  example,  genenliaing  the  formula  of  Figure  5  creates 
the  dialog  box  of  Fignre  6-a.  and  the  code  would  be 
changed  as  shown  in  Figure  6-b.  The  new 
Centec-Boeween-X  function  can  now  be  used  in  other 
formulas.  It  will  also  be  added  to  the  C32  graphics  func¬ 
tions  menu,  so  it  can  be  easily  retrieved  later. 

The  intelligent  copying  and  generalizing  discussed  here 
helps  the  user  gener^  correct  constraints  by  example. 
Without  these  aids,  it  is  quite  common  to  forget  (o  change 
one  or  more  of  the  references  when  formulas  are  copied. 
Generalizing  also  helps  the  programmer  decrease  the  size 
of  the  code  by  juomoting  die  reuse  of  existing  formulas. 
Fuujre  research  will  invesugate  further  ways  to  use 
generalization. 

TRAaNG  AND  DEBUGGING 

Experience  with  Garnet  and  all  other  constraint-based  sys¬ 
tems  shows  that  people  have  a  difficult  time  debugging 
their  formulas.  The  primary  proUem  is  (hat  constraints  ate 
not  local  because  values  in  one  object  can  affect  values  in 
many  different  objects.  Therefore,  C32  provides  a  set  of 
tracing  and  debugging  tools. 

The  most  straightforward  method  is  to  simply  use  the 


tSuce  dlii  if  t  more  radioi  dung e  dua  die  infened  iku  dieeuned  io 
die  pRvioiu  aaction.  il  leeim  pmdcni  lo  require  coniiniuliaa. 


CmnmraUtingKt's  .irnfi  formula  loKjh  ||cZcc!|| 

Nw  Fmctfaai  Nmm;  iCcatcr*B 

*nr«ca-Xl 

.witid:  tvKEib'  '■>  .•!>■  Li?<'2 ! 

it  nlwnd  u  4S:  jtbjl  | 
t2i«t«tndta  u:  Itbgj 

L  . 

(a) 

(defun  Cencec-Between-X  (ob^l  ob)2) 

(floor  (*  (qv  ob}l  :leftl 
(qv  objl  :widch) 

(qv  obj2  :lefr) 

I-  (gv-indir«ct  ;widtn))) 

2) ) 

(formui*  ’ (Center-Betv««n-x  rl  t2) 1 

(b) 

Figure  6:  (a)  The  dialog  box  for  generalizing  from  a  for¬ 
mula.  All  the  values  shown  arc  the  defaults 
provided  by  C32.  After  ihc  user  hits  OK.  the 
formula  of  Figure  5-b  is  converted  automaucally 
into  (he  function  shown  here  in  (b). 


spreadsheet  to  exercise  and  moriior  ihc  user  interface  in 
action.  Often,  seeing  the  current  values  of  all  (he  slots  is 
sufficient  to  determine  the  problem.  To  help  relate  the  ceils 
and  objects,  commands  arc  provided  U3  blink  the  object 
associated  with  a  cell,  or  the  ceils  for  an  object 

Other  commands  display  arrows  in  the  spruidshect  to  show 
which  cells  are  used  in  the  computation  of  (he  currem  cell 
(see  Figure  7-a)  or  the  cells  that  use  the  value  of  this  cell 
(Figure  7-b).  We  are  exploring  additional  graphical  con¬ 
straint  debugging  tools. 
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(b) 

Figure  7:  C32  will  display  anows  to  show  which  skxs  the  cumm  one  depends  on  or  which  slots  depend  on  the  cuiient  cell. 

(a)  shows  ihaf  the  :l«fc  of  STRZNGl  depends  on  the  .‘left  of  the  rectangle,  and  the  : widths  of  the 
rectangle  and  iiaelf  (since  it  is  centered),  (b)  shows  that  the  :  left  of  the  rectangte  is  used  by  the  ;  left  of  the 
string  and  :xl  of  the  line.  In  both  views,  ihe  arrows  point  to  the  slot  being  used. 

MHSnTANCE  ferent  current  value  because  their  string  and  font  values  are 

Garnet  a  protocype-instance  model  instead  of  the  con*  diffeteM.  Therefore,  if  a  formula  is  inherited,  the  inherited 
ventional  class-insiance  model.  This  means  that  any  object  marker  is  shown  nwt  to  the  formula  icon  in  the  spreadsheet 

can  be  used  as  a  prototype  for  a  new  set  of  objects;  there  is  ihe  value  part  is  not  shown  in  italics, 

no  distinction  between  and  instances.  One  result  of 

this  is  that  each  instance  decides  which  slots  to  inherit  and  INTEGRATION  WITH  OTHER  TOOLS 

which  to  override.  For  example,  many  graphical  objects  do  There  are  many  different  mechanisms  and  tools  in  the  Car¬ 
not  have  a  :  filling-style  skH,  but  rather  inherit  this  net  system.  Therefore,  unlike  previous  spreadsheet  systems 

value.  Inherited  slots  are  shown  in  italics  with  the  <X)  icon  such  as  NoPump,  C32  does  not  have  to  address  every 

next  to  their  value  (see  Figure  1 ).  aspect  of  user  interface  design. 

Inheritance  in  Garnet  is  determined  dynamically.  This  When  the  programmer  wants  graphics  in  Carnet  to  respond 

means  diat  setting  the  value  of  a  slot  which  used  to  be  to  the  mouse  or  keyboard,  an  Inietactor  object  (9, 11]  is 

inherited,  changes  the  slot  to  be  local  with  the  new  value.  attached  to  the  graphics  to  handle  the  input  events.  TlKre 

C32  shows  this  by  removing  the  inherited  icon  after  a  slot  is  a  standard  protocol  that  the  Inieractors  use  to  query  and 

is  edited.  When  a  local  sloi  is  deleted  from  an  object  in  modify  the  graphics.  Since  Interactors  are  objects,  they  con 

Gainet,  the  system  looks  in  the  prototype  to  see  if  that  same  also  be  read  into  C32.  Unlike  graphical  objects,  however, 

slot  exists  there,  and  if  so,  the  slot  becomes  inherited.  Inieractors  are  not  visible  so  they  cannot  be  pointed  at. 

Therefore,  if  a  slot  is  deleted  in  (332  but  there  is  a  value  Therefore,  there  are  commands  to  display  a  menu  of  all  the 

that  can  be  inherited.  C32  will  change  the  display  to  show  Interactots.  of  all  those  that  affect  a  particular  graphic  ob- 

ihe  inherited  value.  This  makes  it  clear  to  the  user  that  ject.  or  all  those  that  respond  to  a  particular  input  event 

although  (he  local  slot  is  removed  from  the  instaiKe,  there 

is  still  a  legal  value  for  it  C32  can  also  be  used  with  the  Lapidary  interactive  user 

interface  design  tool  f8|.  Lapidary  allows  the  designer  to 
Fonnulas  can  also  be  inherited.  In  this  case,  llicrc  is  often  a  draw  pictures  of  wlui  ilic  user  iiiicrfaLC  sUiidd  ItMii  like 

differciu  current  value  for  the  slot  even  (hough  the  formula  and  then  demonstrate  how  it  should  act  Although 

is  the  same  as  the  prototype’s.  Fbr  example,  the  :  width  Lapidary  provides  an  iconic  interface  to  many  common 

slot  of  a  text  objea  usually  contaias  a  formula  that  com-  constraints,  C32  can  be  used  when  more  complex  or  cus- 

puies  the  width  based-on  the  object’s  font  and  string  value.  tom  constraints  are  necessary. 

Most  text  (Ajecu  inherit  this  fonnula,  but  still  have  a  dif- 
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STATUS  AND  FUTURE  WORK 
Tlie  spieadsiieet  described  here  is  mostly  wwking.  and  we 
expea  to  release  it  to  Gama  users  w^in  ibe  next  few 
uMollis.  Their  feedback  will  be  valuable  in  deciding  what 
feamies  to  add  and  modify.  We  expea  lo  explore: 

•  Other  ways  10  use  demoostiatioa  to  create  formulas. 

•  Mote  devo  geaeniizafioiis  Cram  existing  formulas. 

•  Beam  connection  with  Interacton.  There  is  a  well- 
defmed  protocol  between  Imenctors  and  graphic  objects 
that  serve  as  feedback  objects.  The  spreadshea  could  set 
the  appropriate  fields  of  the  graphic  objea  automatically 
if  the  objea  was  placed  in  a  slot  of  the  Intetactor.  as  is 
done  by  Lapidary  [8]. 

•  Ways  to  use  C32  to  create  objects  from  scnuch,  so  C32 
can  be  used  as  an  interface  boilda.  Once  objects  have 
been  created  in  memory.  Gama  already  contains  a  built* 
in  mechanism  that  will  write  them  to  a  file  so  they  can  be 
used  by  real  aiplicaiions. 

CONCLUSION 

The  C32  qxteadsfaea  contains  a  numba  of  novel  feamies. 
including  dte  use  of  demanstraiionai  techniques  to  generate 
objea  tefexences,  automatic  generalization  of  formulas, 
and  graphical  tracing  and  debugging.  These  make  it  easier 
to  use  than  previous  spieadshea-based  graphical  tools. 
C32  enhances  the  Gama  usa  interface  developmerit  en- 
vtranment  by  providing  an  appropiate  mechanism  for 
specifying  complez.  custom  constraints,  which  occur  fre¬ 
quently  in  user  imerface  software.  C32  has  demonstrated 
that  a  spreadshea  tool  can  be  a  valuable  addition  to  an 
existing  constraint-based  system,  and  that  it  is  possible  to 
ga  totally  carried  away  in  acronym  building. 
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ABSTRACT 

Marquise  is  a  new  interactive  tool  that  allows  virtually  alt 
of  the  user  interfaces  of  graphical  editors  to  be  created  by 
demonstration  without  programming.  A  “graphical 
editm’’  allows  the  user  to  create  and  manipulate  graphical 
objects  with  a  mouse.  This  is  a  very  large  cl^  of 
programs  and  iiKludes  drawing  programs  like  MacOraw. 
graph  layout  editors  like  MacProject,  visual  language 
editors,  and  many  CAD/CAM  programs.  The  primary  in¬ 
novation  in  Marquise  is  to  allow  the  designer  to 
demonstrate  the  overall  behavior  of  the  interface.  To  im¬ 
plement  this,  the  Marquise  framework  contains  knowledge 
about  palettes  for  creating  and  specifying  properties  of  ob¬ 
jects,  and  about  operations  such  as  selecting,  moving,  and 
deleting  objects.  The  interactive  tool  uses  the  framework 
to  allow  the  desi^ier  to  demonstrate  most  of  the  end  user’s 
actions  without  programming,  which  means  that  Marquise 
can  be  used  by  non-programmers. 

KEYWORDS:  User  Interface  Software,  User  Interface 
Management  Systems,  Interface  Builders.  Demonstrationai 
Interface,  GarneL 

INTRODUCTION 

One  important  goal  of  the  Gamci  project  (61  is  to  allow 
user  interface  designers  who  are  not  programmers  to  design 
and  implement  the  took  and  feel  of  user  interfaces.  The 
Marquise  fool  is  the  newest  addition  to  the  Garnet  environ¬ 
ment,  and  it  ties  together  ail  the  previous  tools,  while  sup¬ 
porting,  for  the  first  time,  interactive  specification  of  the 
entire  user  interface. 

In  particular.  Marquise  allows  the  overall  graphical  ap¬ 
pearance  of  the  interface  to  be  drawn,  and  the  behaviors  for 
object  creation,  selection  and  manipulation  to  be 
demonstrated. 

Unlike  many  previous  tools  Afhich  concentrate  on  widgets. 
Marquise  is  aimed  mostly  at  the  main  drawing  window  of 
graphical  editors  where  the  u.scr  creates  and  manipulates 
graphical  objects  with  a  mouse.  For  example,  with  Mar¬ 
quise  you  can  demonstrate  how  the  rubber  banding  will 


appear  as  you  move  the  mouse,  rather  than  having  this  as  a 
hard-wired,  unchangeable  component.  Another  important 
capability  in  Marquise  is  demonsuaiing  the  modes  of  the 
interface.  Although  “mode-free  "  interfaces  are  often 
touted,  all  modem  graphical  interfaces  are  in  fact  highly 
moded.  For  example,  in  most  drawing  tools  such  as 
Macintosh  MacDraw,  a  palette  controls  whether  the  next 
mouse  click  will  select  an  object,  insert  a  text  string,  or 
draw  a  rectangle,  circle,  polygon,  etc.  Other  modes  include 
the  cunent  colors,  line  styles,  and  arrowhead  styles  for  the 
objects  that  will  be  created.  Marquise  provides  an  intuitive, 
demonstrationai  method  for  specifying  the  modes  that  con¬ 
trol  and  are  affected  by  an  operation. 

With  Marquise,  we  have  concenuated  on  providing  com¬ 
plete  control  of  when  and  how  the  behaviors  are  initiated. 
The  primary  innovations  in  Marquise  are:  (1)  the  use  of 
special  icons  to  represent  the  mouse  positions  while 
demonstrating  the  behavior,  so  the  designer  can  then 
demonstrate  what  happens  at  those  locations,  (2)  sophis¬ 
ticated  control  over  the  locations  where  those  events  should 
take  place  to  begin  and  end  behaviors.  (3)  a  “mode  win¬ 
dow”  to  make  explicit  the  modes  of  the  interface  that  con- 
tr''*  the  behaviors  and  values,  (4)  ihc  formali/auon  of 
“paleues”  to  conuol  motlcs  and  object  properties,  and  (5) 
the  ability  to  interactively  specify  the  attributes  for  built-in 
layout  operations  and  objects. 

Marquise  stands  for  Mostly  Automated,  Remarkably  Quick 
User  Interface  S^oftwarc  Environment.  (A  “marquise”  is  a 
gem  having  the  shape  of  a  short,  pointed  oval  with  many 
facets.)  Marqui.se  is  part  of  the  Garnet  system,  which  is  a 
comprehensive  u.scr  interface  development  environment 
written  in  Lisp  for  the  X  window  system.' 

RELATED  WORK 

Previous  design  tools  have  shown  that  it  is  possible  to  in- 


’Thc  (iiimci  syiictn  is  jvmiiihlc  by  arnsnymsius  ('11’  Although  Mar 
quisc  IJ  not  ycl  rGady  lor  Jislnbuiion  as  this  pupcr  is  being  wnuen.  you 
can  gel  the  loutkil.  the  tjill  inlcrtacc  builder,  and  l.apidary  Send  mail  to 
Gacnet@CS  .  Cinu  .  edu  lor  mlomtaliun 


-  116 


Marouise:  CrM»«qg  Complete  User  Interfaces  by  Demonstnuion 

tencdvely  ^xcify  the  graphical  appearance  and  behavior 
of  limited  parts  of  an  application’s  user  interface.  For  ex¬ 
ample,  many  interface  builders,  such  as  the  NeXT  Interface 
Builder.  UlMX  fw  Motif,  Druid  [8],  and  Gill  [7],  allow  the 
designer  to  interactively  specify  the  placement  of  widgets. 
Peridot  [3]  allows  new  widgets  to  be  created  interactively 
without  programming,  and  Lapidary  [4]  allows  application- 
specific  graphical  objects  to  be  d^onstrated.  Marquise 
goes  beyond  these  tools  since  it  supports  creating,  editing, 
imd  deleting  of  objects  at  run  time,  and  allows  the  overall 
behavior  to  be  defined.  DEMO  [10]  used  the  idea  of 
demonstrating  the  end-user’s  actions  that  start  a  behavior 
(called  the  "stimulus”)  and  then  demonstrating  the 
response  to  that  stimulus.  DEMO  II  [1]  added  sophis¬ 
ticated  techniques  for  inferring  constraints  to  control  how 
objects  are  placed  or  moved.  Marquise  uses  the  stimulus- 
response  id^  here  caUed  "train"  and  "show."  but  con¬ 
centrates  on  which  high-level  actions  are  appropriate  and 
the  context  of  the  stimulus. 

Some  [nevious  systems  have  provided  frameworks  to  help 
code  graphical  editors.  Unidraw  [9]  and  many  graph 
editors  (e.g.,  [2])  provide  a  standard  set  of  built-in  opera¬ 
tions  as  methods,  and  the  designer  writes  code  to  override 
these  methods  for  the  specific  application.  However,  none 
of  these  other  systems  allow  new  behaviors  to  be  defined 
by  demonstration. 

USER  INTERFACE 

The  basic  windows  for  Marquise  are  shown  in  Figure  1. 
There  is  a  palette  of  objects  that  can  be  drawn,  some 
palettes  for  controlling  the  properties  of  those  objects,  and 
a  set  of  commands  in  a  menubar.  In  all  conventional  inter¬ 
face  builders  there  are  two  modes:  Build  and  Run,  where  in 
Build  mode  the  designer  constructs  the  interface,  and  in 
Run  mode  it  is  tested.  Marquise  adds  two  additional  modes 
to  demonstrate  behaviors:  Train  and  Show.  Train  mode  is 
used  to  demonstrate  what  the  end  user  will  do,  and  Show 
motfe  is  used  to  demonstrate  the  system’s  response  to  that 
actkm.  A  different  mouse  cursor  for  each  mode  insures 
that  the  designer  always  knows  what  the  current  mode  is. 

In  Build  mode,  the  static  parts  of  the  interface  arc  drawn. 

For  example,  the  designer  might  add  to  the  window  some 
widgets  that  should  always  be  visible.  Lines  could  be 
added  as  decorations.  Many  applications  contain  palettes 
that  show  which  objects  can  ^  created,  or  that  show 
various  values  for  a  property  (like  color,  line-style,  etc.). 
These  palettes  are  drawn  with  Marquise  in  Build  mode.  In 
Run  mode,  the  interface  can  be  exercised  to  see  how  it  will 
operate  for  the  end  user. 

In  Train  mode,  the  designer  operates  the  mouse  and 
keyboard  in  the  same  way  the  end  user  would,  and  then 
goes  into  Show  mode  to  demonstrate  what  the  system's 
response  should  be.  While  in  Train  mode,  the  end-user 
behaviors  are  operational,  but  in  addition,  the  keystrokes 
and  mouse  movements  are  saved.  In  Show  mode,  the 
designer  can  create  and  edit  objects  exactly  the  same  as  in 
Build  mode,  except  that  the  operations  are  remembered  so 
they  can  be  attached  to  the  events  demonstrated  in  Train 


Figure  1: 

The  main  Marquise  wirtdaws:  ihe  basic  object  palette  on 
the  left,  the  main  work  area,  and  the  palette  for  controll¬ 
ing  the  color  and  halftones  for  filling-siyies  and  line- 
styles  at  the  bottom.  The  designer  is  creating  an  inter¬ 
face  with  a  “create  palette"  at  the  top  containing  two 
types  of  nodes  and  two  types  of  links.  The  node  at  the 
lower  right  of  the  work  window  is  selected.  The  Mar¬ 
quise  commands  are  in  ihc  menubar  at  the  top.  The 
“Constraints"  menu  allows  graphical  constraints  to  be 
specified.  The  “Behaviors”  menu  allows  objects  to  be 
declared  as  palettes,  and  displays  ihe  mode  and  feed¬ 
back  window 


kl 


Figure  2: 

(a)  The  icons  that  show  where  ihe  moasc  was  pressed, 
moved  to,  released,  clicked  (pressed  and  released  in  the 
same  place),  double  clicked,  and  double  clicked  and 
released,  (b)  In  Train  mode,  the  designer  pressed  the 
mouse  down  and  moved,  and  then  m  Show  mode,  drew 
a  doited  line  as  the  inicnm  feedback,  tc)  Going  back  to 
Tram  mode,  the  designer  released  the  mouse  button,  and 
in  Show  mode,  deleted  the  dotted  line  and  drew  a  solid 
line. 


mode. 

As  an  example,  here  i.s  how  the  designer  would 
demonstrate  that  when  litc  mou.se  button  goes  down,  a 
feedback  doited  line  should  be  drawn  which  follows  the 
mouse,  and  then  when  the  button  is  released,  the  doued  line 
should  be  cra.sed  and  a  real  line  drawn.  First,  the  designer 
would  go  into  Train  mode,  prc.s.s  down  ihc  mouse  button, 
and  move  away  from  the  initial  press.  Without  releasing 
the  mouse  button,  the  designer  would  change  to  Show 
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Figure  3: 

The  feedback  window  for  behaviors.  At  the  top  is  a 
puU>down  menu  of  commands,  then  the  name  of  the 
behavior,  then  the  oi^ects  that  participate  in  the  be¬ 
havior,  and  finally  the  events  and  actions.  Pushing  on 
the  buttons  displays  a  popup  window  of  the  other  pos¬ 
sible  choices.  Changing  the  option  at  the  beginning  of  a 
“sentence”  will  change  the  options  available  for  the 
rest  of  the  sentence.  An  entire  section  of  the  window 
can  be  selected  and  cut,  copied,  etc. 


mode.  The  window  will  now  contain  two  icons  which 
show  where  the  mouse  was  pressed  and  to  where  it  was 
moved.  Now  in  Show  mode,  the  designer  draws  a  doited 
line  between  the  icons  (Figure  2-b).  Marquise  infers  that  a 
dotted  line  should  be  created  on  the  down  press  and  one 
end  should  follow  the  mouse  as  it  moves.  Then  the  desig¬ 
ner  presses  the  mouse  button  somewhere  on  the  back¬ 
ground  and  switches  to  Train  mode  with  the  mouse  button 
still  down,  so  the  mouse  release  can  be  demonstfated.  Be¬ 
cause  this  second  demonstration  does  not  include  a  down- 
press,  the  original  down-press  icon  is  retained.  Next,  in 
Show  mode,  the  designer  deletes  the  dotted  line  and  draws 
a  solid  line  from  the  initial  down  press  icon  to  the  final 
button  release  icon  (Figure  2-c).  This  entire  behavior  lakes 
less  than  30  seconds  to  demonstrate,  and  very  few  new 
concepts  or  commands  are  necessary,  since  the  designer 
already  knows  how  to  draw  and  delete  objects  in  the  editor. 


If  the  mouse  had  been  pressed  and  released  in  the  same 
place,  then  a  click  icon  would  be  displayed  instead  of  the 
down,  move  and  up  icons.  Double-clicking  or  double¬ 
clicking  followed  by  a  move  arc  also  supported.  To  allow 
modes  to  be  changed  white  mouse  buttons  are  being  held 
down  and  while  the  mouse  is  at  a  particular  place,  keyboard 
accelerator  keys  are  used  to  change  modes. 

Marquise  generalizes  from  the  designer’s  example  actions 
to  create  the  user  interface.  Any  system  thm  tries  to 
generalize  will  sometimes  guess  wrong.  Various 
mechanisms  have  been  explored  in  other  systems  to  show 
the  user  what  has  been  gu^sed,  so  that  users  can  verify  and 
correct  the  inferences.  Older  systems,  such  as  Peridot 
[3]  and  Dniid  [8],  required  the  user  to  confum  each  in¬ 
ference,  which  can  be  disrupting  and  annoying.  In  Mar¬ 
quise,  a  feedback  window  (Figure  3)  shows  the  inferred 
operation.  The  labels  and  buttons  can  be  read  as  a  sen¬ 
tence,  and  the  buttons  can  be  pressed  to  pop  up  a  list  of 
other  alternatives  and  change  the  values.  Since  Marquise 
appears  to  guess  correctly  most  of  the  lime,  .Marquise  ap¬ 
plies  the  inferred  property  immediately,  and  allows  ihe 
designer  to  venfy  or  change  it  afterwards  in  the  feedback 
window. 

ENVIRONMENT 

Marquise  makes  heavy  use  of  many  features  of  Garnet. 
Garnet  uses  a  retained  object  model  and  a  prototype- 
instance  object  system.  This  means  that  there  is  an  object 
in  memory  for  every  object  on  the  screen,  and  that  any 
object  can  be  used  as  the  prototype  to  make  a  copy  or 
instance.  Since  ail  Carnet  objects  ore  represented  the  same 
way,  there  is  a  single  mechanism  for  copying  and  creating 
objects,  whether  they  arc  simple  recuuigles  or  aggregates 
containing  many  componems.  Therefore,  Marquise  can  al¬ 
ways  generate  appropriate  code  to  create  items  for  run 
lime,  without  having  to  know  the  types  of  the  objects  the 
designer  has  drawn. 

Implementing  the  behaviors  that  arc  demonstrated  is  quite 
straightforward  once  they  have  been  determined  because 
Marquise  can  create  instancc.s  of  “inicractor”  objects 
[5)  and  fill  in  the  appropriate  attributes.  Each  inicractor 
implements  a  particular  kind  of  behavior,  such  as  selection, 
creation,  moving,  etc.,  and  contains  aiiribules  to  support 
most  of  the  popular  inicraciion  styles. 

The  object  system  supports  constraints,  which  are  relation¬ 
ships  that  arc  declared  once  and  maintained  by  the  system. 
Constraints  arc  used  to  maintain  the  rclaiioaships  among 
the  graphical  objects  in  Marquise.  Constraints  can  also  be 
u.scd  to  connect  application  data  to  Marquisc-gcncratcd  in¬ 
terfaces,  or  else  application-specific  call-back  procedures 
can  be  invoked  when  a  behavior  is  completed. 

Garnet  contains  u  number  of  other  high-level  interactive 
tools,  such  as  the  Lapidary  tool  for  creating  individual 
widgets  or  objects,  the  Gill  tool  for  editing  dialog  boxes, 
the  Jade  tool  for  auiomaiicaily  creating  dialog  boxes,  and 
the  C32  spreadsheet  system  for  specifying  complex  con- 
su^ints.  Bccau.se  all  the  tools  use  the  .same  data  structures 
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aod  file  format  for  describing  objects.  Marquise  does  not 
have  to  re-implement  the  functionality  already  provided  by 
those  tools — it  can  concentrate  on  the  global  tehavior.  The 
designer  can  have  more  than  one  tool  operating  at  the  same 
time,  and  use  whichever  is  appropriate  for  the  current  part 
of  the  task. 

FRAMEWORK 

Marquise  is  able  to  construct  the  interface  from  the 
demonstrations  because  it  has  built-in  knowledge  of  the 
kinds  operations  that  are  common  in  graphical  editors. 
This  knowledge  is  part  of  the  underlying  Marquise 
firamewwk  that  supports  die  interactive  front  end.  The 
operadotts  include:  creating  an  object  of  the  type  in  a 
I^ette,  selecting  objects,  diiecdy  manipulating  the  size  and 
shape  with  the  mouse,  specifying  properties  of  objects 
(color,  font,  etc.)  with  a  palette  or  property  sheet,  miscel¬ 
laneous  editing  operations  (deleting,  duplicating,  etc.),  and 
application-specific  commands. 

Modaa 

It  is  very  common  in  user  interfaces  for  different  behaviors 
to  result  from  the  same  action,  detennined  either  by  the 
location  of  the  initiating  event  or  by  the  value  of  a  global 
mode  variable.  As  an  example  of  the  fust  case,  in 
MacProject  II  for  the  Macintosh,  pressing  the  mouse  button 
down  will  start  text  editing  (if  inside  a  box),  select  a  box  (if 
at  its  edge),  create  a  new  box  (if  in  the  background),  draw  a 
link  between  two  boxes  (if  pressed  in  one  box  and  released 
in  another),  grow  a  box  (if  pressed  on  a  selection  handle), 
or  draw  a  link  and  create  a  box  (if  pressed  in  one  box  and 
released  outside).  Designers  specify  these  differences  in 
Marquise  by  demonstrating  the  different  operations.  Mar¬ 
quise  notices  what  objects  are  underneath  the  demonstrated 
events  (including  the  mouse  release),  so  it  can  distinguish 
the  correct  times  to  use  the  different  behaviors.  The  object 
being  used  is  shown  in  the  feedback  window,  and  the  but¬ 
tons  there  can  be  used  to  edit  the  choice. 

In  other  cases,  the  selection  of  the  behavior  is  determined 
by  the  value  of  a  global  mode  variable,  which  is  set  by  a 
palette  or  an  external  application  program.  To  make  these 
modes  explicit  and  visible.  Marquise  provides  a  mode 
window,  shown  in  Figure  4,  which  lists  each  mode  variable 
and  its  current  value.  The  values  displayed  wilt  change  as 
the  interface  is  operated,  and  the  designer  can  directly  edit 
the  values  for  user  modes.  When  the  value  has  a  fixed  list 
of  choices,  these  are  available  in  a  pull-down  menu.  To 
make  an  interaction  dependent  on  whether  a  mode  has  the 
current  value,  it  is  only  necessary  to  click  on  the  check  box 
next  to  the  mode  name  before  dcmon.suuting  the  behavior. 
When  a  user  ^tion  causes  a  mode  to  change,  this  can  be 
demonstrated  by  simply  editing  the  value  in  the  mode  win¬ 
dow  while  in  Show  mode. 

The  combination  of  the  icons  and  mode  window  make  the 
conu^l  of  the  behaviors  explicit  and  direct.  In  contrast, 
DEMO  II  (1]  uses  multiple  examples  to  determine  in  which 
situations  the  operations  should  occur,  which  we  feel  will 
be  more  prone  to  errors. 


Paiattas 

One  of  the  im{K)rtant  innovations  in  the  Marquise 
framework  is  the  formalization  of  a  palette,  which  is  a  list 
of  options,  usually  presented  graphically.  Each  palette  con¬ 
trols  a  single  value  or  mode.  Since  palettes  are  conven¬ 
tional  interaction  techniques  internally  (i.e.,  they  arc 
usually  a  list  of  buttons),  their  internal  behavior  (how  the 
user  changes  the  current  selection  and  what  feedback 
shows  the  selected  objects)  can  be  easily  specified  using 
Lapidary  or  Marquise.  The  innovation  here  is  the 
automatic  connection  of  the  palette  to  the  rest  of  the  inter¬ 
face. 

Marquise  identifies  two  main  classes  of  palettes;  create 
paleues  and  property  palettes.  A  create  palette  contains  the 
different  kinds  of  objects  that  can  be  created.  For  example, 
the  create  palette  for  MacOraw  II  contains  a  selection  ar¬ 
row,  strings,  lines,  rectangles,  rounded-rectangles,  ovals, 
arcs,  curves,  polygons,  and  text  fields.  A  create  palette  for 
a  CAD/CAM  program  for  circuit  boards  might  have  a  long 
list  of  different  IC  types,  plus  wires,  pads,  etc. 


Figure  4: 

The  mode  window  showing  the  defined  modes  and  their 
cuiTcni  values.  The  designer  can  click  on  ihe  check  box 
at  the  Icfi  of  a  row  u>  indicate  that  the  next  action 
depends  on  the  mode  having  the  specified  value. 
Modes  based  on  pulctlcs  change  as  the  palette  is 
operated.  Applications  can  also  directly  sot  a  mode,  and 
one  of  the  actions  resulting  from  a  behavior  might  be  a 
mode  change. 


A  property  palette  contains  the  different  values  for  a  single 
properly.  MacDraw  II  has  a  property  palette  for  the  filling 
style  at  the  top  of  the  window,  and  property  palettes  for  the 
line  style,  font  size,  font  style,  etc.  in  pull-down  menus. 
Marquise  supports  palettes  which  arc  not  always  visible, 
and  a  palette  can  even  be  a  sub.sct  of  the  items  in  a  different 
widget  (e.g.,  a  section  of  a  pull-down  menu).  In  addition, 
the  list  of  choices  can  be  dynamically  changing,  for  ex¬ 
ample,  if  the  application  has  commands  to  read  new 
libi^ics  or  to  edit  the  palciic  iLsclf. 

There  arc  two  imponant  distinctions  between  ihc  two  types 
of  palettes.  First,  the  create  palette  usually  enables  dif- 
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ferent  interaction  techniques.  For  example,  the  selection 
arrow  enables  selt  'tion,  the  rectangle  enables  dragging  out 
new  rectangles,  and  the  text  string  enables  clicking  to  start 
entering  text  A  property  palette  is  assumed  to  only  set 
values  of  properties  and  not  to  control  interaction 
techniques.^  Note  that  a  create  palette  can  enable  various 
kinds  of  behaviors,  such  as  selecting  and  deleting,  and  not 
just  creating.  The  sectmd  difference  between  the  two  type' 
of  palettes  is  that  Marquise  assumes  that  objects  cannot 
change  type,  so  that  selections  in  the  create  p^tte  cannot 
affea  the  selected  objects.  However,  clicking  in  property 
palettes  usually  changes  the  value  of  that  property  for  the 
selected  objects. 

Craata  Palatfas.  To  make  a  create  palette,  the  designer 
only  needs  to  draw  the  set  of  objects  using  Marquise  or 
Lapidary,  select  them,  and  declare  them  to  be  a  create 
palette  using  a  menu  commtmd.  Marquise  will  then  add  a 
tow  to  the  mode  window  (Figure  4)  showing  the  palette 
and  its  current  value.  The  designer  would  select  die  new 
row  in  the  tnode  window,  click  on  each  item  in  the  palette 
to  put  the  system  into  the  appropriate  mode,  and 
demonstrate  the  desired  behavior. 

The  create  palette  has  some  additional  attributes  which 
control  common  features  found  in  graphical  editors.  Some 
of  these  can  be  demonstrated,  and  the  rest  are  specified  in 
dialog  boxes. 

•  In  some  palettes,  when  the  user  clicks  on  an  item,  that 
sets  up  a  mode  so  thau  the  next  operation  will  create  the 
kind  of  object  represented  by  that  item.  This  was  shown 
in  the  example  above,  and  is  the  way  that  MacDraw 
works.  In  other  cases,  clicking  in  the  ^ette  causes  the 
object  to  be  created  immediately  (e.g..  at  the  current 
mouse  position  for  a  popup  menu  of  choices,  or  at  a 
comput^  place  if  the  objects  are  laid  out  automatically 
by  the  system).  Other  times,  objects  are  dragged  off  the 
palette. 

•  After  an  object  is  created,  some  applications  select  the 
newly-creat^  object,  some  leave  the  selection  un¬ 
changed,  others  add  the  new  object  to  the  selection  set  (if 
objects  were  selected  before  the  create),  and  yet  others 
clear  the  selection. 

•  Sometimes,  after  the  object  is  created,  the  mode  of  the 
create  palette  wiU  change.  For  example,  in  MacOraw  II. 
after  creating  a  rectangle,  the  mode  changes  back  to 
selection  (the  arrow).  However,  if  you  double-click  on 
the  palette,  the  mode  does  not  change  after  creation.  In 
the  original  M%;Draw,  all  object  creation  modes  changed 
back  to  selection  except  for  text  su-ings. 

Property  Palettes.  Properly  palciics  allow  the  user  to  con¬ 
trol  the  value  of  properties  of  objects.  Typically,  the  same 
palette  is  used  for  specifying  the  global  default  value  used 
for  newly-created  objects,  and  for  changing  the  property  of 
selected  objects.  The  same  palette  might  al.so  be  used  to 


^is  restncuon  could  be  Utled  in  the  future  if  it  becomes  onerous,  but 
It  is  consistent  with  the  behavior  of  all  editors  we  have  studied. 


show  the  value  for  the  selected  object 

To  create  a  property  palcuc.  the  designer  only  needs  to 
draw  a  set  of  objects  representing  the  different  values  (for 
example,  the  line-style  items  of  Figure  5),  and  declare  them 
to  be  a  property  paieue.  Marquise  then  checks  whether  a 
single  property  seems  to  change  in  each  element  (as  it  does 
in  Figure  5  and  in  most  graphical  property  paleues),  and  if 
so,  proposes  this  as  the  property  to  use.  Alternatively,  the 
user  can  specify  the  name  of  the  property  and  the  value  for 
each  item  of  the  paieue. 


y 
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Figure  5: 

After  drawing  this  picture,  the  designer  would  select  the 
lines,  and  declare  them  to  be  a  ptropeny  palette.  M^- 
quise  would  notice  that  the  line-style  changes,  and 
would  create  an  appropriate  palette  description. 


Each  primitive  Camel  object  describes  which  properties  arc 
relevant  to  it,  and  the  designer  can  add  additional  properties 
for  application-specific  objects.  Therefore,  Marquise  can 
automatically  guess  which  properties  are  probably  relevant 
to  each  type  of  object  that  is  created.  These  guesses  are 
reflected  in  the  feedback  and  mode  windows  (Figures  3  and 
4),  and  if  Marquise  guesses  wrong,  then  the  designer  can 
adjust  the  values. 

Some  atuibutes  for  properly  palettes  provided  by  Marquise 
are: 

•  Whether  setting  the  property  of  a  particular  (selected) 
object  also  changes  the  global  default  used  when  a  new 
object  is  created. 

•  If  an  object  is  selected  that  docs  not  have  the  property 
represented  by  the  palette  (e.g.,  if  (he  palcuc  is  for  the 
font  property  and  a  line  is  selected),  whether  the  palcuc 
goes  inactive  (greyed  out)  or  not.  When  there  arc  mul¬ 
tiple  objects  selected,  whether  the  palcuc  is  valid  if  at 
least  one  of  the  objects  has  thi.s  property,  or  only  when  all 
of  the  objects  have  this  property. 

•  When  an  object  is  selected,  whether  the  palcuc  shows  the 
value  of  that  object.  If  more  than  one  object  is  selected, 
then  the  palette  might  show  the  value  only  if  all  objects 
have  the  same  value,  pick  the  value  of  one  of  the  objects 
to  show,  show  the  global  dclauil  value,  or  ju.si  be  cleared 
to  .show  no  value. 

•  If  the  palette  docs  not  echo  the  value  of  the  property 
when  (he  selection  changes,  then  the  newly  selected  ob¬ 
ject  might  gel  the  current  value  of  the  property  (as  op¬ 
posed  to  requiring  another  click  in  the  palcuc  after 
changing  the  selection). 

Positions  of  nsw  objects 

Once  Marquise  knows  which  object  to  create,  there  is  then 
the  question  of  where  and  how  to  create  it.  There  arc  two 
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possibilities:  the  position  is  computed  automatically,  or  is 
specified  by  the  user  with  the  mouse. 

Automatic  Layout  Garnet  has  built-in  routines  for  list, 
table,  tree,  and  graph  layout.  These  automatically  place  the 
nodes,  rather  than  requiring  the  user  to  specify  a  location. 
Each  type  of  layout  has  a  set  of  methods  for  creating  and 
deleting  nodes,  and  Marquise  allows  the  designer  to 
demonsnaiB  how  these  methods  are  invoked  and  how  their 
attributes  are  specified.  Many  previous  systems  have  al¬ 
lowed  a  designer  to  build  custom  graph  layout  applications 
by  writing  code,  but  Marquise  is  the  fust  to  allow  the  look 
of  the  nodes  to  be  drawn  and  the  editing  behaviors  (creat¬ 
ing,  deleting,  editing  labels,  etc.)  to  be  demonsuated  inter¬ 
actively. 

First,  the  designer  specifies  which  kind  of  layout  is 
desired.^  Next,  the  d^igner  draws  pictures  to  show  the 
grafriiics  for  the  nodes  (and  the  graphics  for  the  arcs  for 
trees  and  graphs).  If  these  have  complex  internal  strucuire. 
then  the  Lapid^  tool  will  be  useful  for  drawing  them. 
The  built-in  layout  algorithms  have  many  attributes  that 
oHitroi  the  display,  and  some  of  these  can  be  demonstrated 
(e.g.,  the  spacing  and  direction).  The  rest  are  specified  in  a 
dialog  box. 

Next,  the  designer  demonstrates  the  creation  behavior. 
Using  knowledge  of  the  type  of  layout  in  use.  Marquise 
tries  to  determine  if  the  new  object  should  be  placed  in 
some  relation  to  a  selected  object,  or  globally  wi^  respect 
to  all  objects.  PCX'  example,  in  a  directed-graph  editor, 
there  mi^t  be  commands  for  "Add  new  child"  and  "Add 
new  parent"  Marqt’se  does  not  try  to  understand  the 
words  in  the  command  names.  Instead,  the  designer  would 
go  into  Run  mode  and  select  a  node,  and  then  in  Train 
mode  the  designer  would  select  the  command.  Finally,  in 
Show  mode,  the  new  object  would  be  created  with  the  cor¬ 
rect  relationship  to  the  selected  node. 

In  some  cases,  the  new  object’s  position  will  not  depend  on 
the  selection,  but  rather  on  glob^  properties.  For  example, 
the  new  object  might  always  go  at  the  end  of  a  list.  In  this 
case,  the  designer  would  make  sure  that  no  objects  are 
selected  before  demonstrating  the  position  of  the  new  ob¬ 
ject,  and  Marquise  would  try  to  determine  the  appropriate 
place  for  the  object.  Alternatively,  the  posiuon  might 
depend  on  some  global  mode,  so  the  appropriate  row  of  the 
mode  window  would  be  selected  before  the  demonstration. 
Usually,  the  position  will  be  obvious  (e.g„  first  or  last),  but 
if  Marquise  cannot  guess  it,  then  currently  the  designer  will 
have  to  write  a  Lisp  function  to  compute  the  position,  pos¬ 
sibly  based  on  values  in  the  mode  window. 

User  Layout  Most  graphical  editors,  however,  require  the 
user  to  expliciUy  specify  the  position  of  new  objects.  The 
example  of  Figure  2  shows  how  the  simple  case  of  a  new 


^Marquite  cannot  infer  a  new  layout  algonthm.  For  example,  if  a  new 
kind  of  graph  layout  is  required,  the  designer  haj  to  program  n  in  Lisp,  hut 
It  can  then  be  used  by  Marquise-gencraicd  programs. 


line  can  be  demonstrated  in  Marquise. 

It  is  very  common  for  the  objects  to  be  constrained  in  their 
placement.  Marquise  has  built-in  knowledge  about  grid- 
ding,  so  this  can  be  easily  used  in  an  application.  A  more 
interesting  problem  is  attachment.  For  example,  an  arrow 
connecting  the  boxes  in  Figure  6  might  always  be  attached 
to  the  centers  of  the  boxes.  In  an  earlier  article  (4),  we 
discussed  how  Lapidary  allows  the  arrow  prototype  to  be 
defined  interactively  with  parameters  that  refer  to  the  ob¬ 
jects  to  which  it  should  be  atuxihed.  Lapidary  creates  con¬ 
straints  that  keep  the  arrows  attached  as  the  objects  move. 
Marquise  allows  the  designer  to  interactively  show  how 
those  parameters  are  filled  in  based  on  the  designer’s  ac¬ 
tions.  For  example,  look  back  at  Figure  I  where  a  creation 
palette  is  being  drawn.  To  demonstrate  the  arrow  creation 
mode,  the  designer  would  select  the  arrow  in  the  create 
palette  while  in  Run  mode.  This  will  change  the  value 
shown  in  the  mode  window  for  the  create  palette  mode 
(Figure  4).  The  designer  would  then  click  on  the  check  box 
next  to  this  mode,  which  tells  Marquise  that  the  mode  is 
significant  for  the  next  operation. 

Assume  that  the  arrow  was  defined  so  that  setting  the  from 
and  to  parameters  with  objects  would  cause  the  line  to  be 
attached  to  those  objects.  In  Train  mode,  the  designer 
would  press  down  inside  a  rounded-rectangle,  and  drag  out¬ 
side.  Then,  in  Show  mode,  the  designer  would  create  an 
instance  of  the  arrow  with  the  shaft  end  inside  the  rounded- 
rectangle  and  the  arrow  end  at  the  icon.  Then,  the 
designer  specifies  that  the  rounded-rectangle  corresponds 
to  the  from  parameter,  and  Marquise  infers  that  it  should 
determine  the  parameter  value  based  on  where  the  mouse  is 
first  depressed,  and  that  the  other  end  should  fol’ow  ihe 
mouse.  Next,  the  designer  demonstrates  the  mouse  buuon- 
up  response  by  deleting  the  feedback  line  and  creating  a 
new  arrow  between  the  two  nodes.  These  nodes  are 
declared  as  the  from  and  to  parameters.  In  the  future,  we 
will  provide  facilities  for  gravity  so  the  designer  could 
specify  that  while  the  mouse  is  moving,  the  feedback 
should  jump  to  the  attachment  points  of  objects  if  they  are 
close  enough. 

Selection 

One  of  the  most  important  operations  in  a  graphical  editor 
is  selecting  objects.  Typically,  the  selected  object  will  be 
shown  by  changing  its  appearance  (e.g.,  to  reverse  video) 
or  by  showing  “selection  handles’’  around  it  (Figure  6) 
Marquise  supports  virtually  any  graphical  response  lo  show 
the  selection.  The  designer  simply  draws  an  example  of  the 
selection  graphics  (or  if  the  object  iLself  changes,  the  desig¬ 
ner  draws  uic  object  first  in  its  normal  and  men  in  its 
.selected  state).  If  ihc  standard  Ga-nct  selection  widget  is 
desired,  then  it  is  only  nccc.ssary  to  go  into  Show  mode  and 
select  an  object.  A  special  line  of  the  mtxlc  window  shows 
which  objects  arc  selected,  and  this  value  can  be  edited  to 
show  whether  the  interaction  being  demonstrated  adds  to 
the  selection  set,  removes  from  it,  clears  it,  etc.  This 
provides  a  uniform,  intuitive  mechanism  for  specifying  al¬ 
most  any  selection  behavior.  The  designer  can  also  specify 
whether  a  different  form  of  feedback  is  u.scd  when  there  arc 
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Figure  6: 

The  arrows  are  constrained  to  be  in  the  centers  of  the 
boxes.  Box  3  has  "selection  handles"  around  it.  which 
show  that  it  is  ;>elected,  and  the  user  can  click  on  white 
handles  to  move  it  or  black  handles  to  grow  it.  The 
formula  that  computes  the  labels  was  hand-coded  using 
C32. 


multiple  selections  (as  in  Macintosh  PowerPoint  and 
Macl^jeci  II). 

Moving  and  Growing  Objacta 

Demonstrating  what  commands  cause  objects  to  be  moved 
and  grown  worics  similarly  to  demonstrating  how  they  are 
created;  first,  the  designer  demonstrates  in  Train  mode 
what  user  action  causes  the  interaction  to  start,  and  then  in 
Show  mode,  moves  or  grows  the  appropriate  object.  Since 
the  standard  editing  actions  work  in  Show  mode,  the  desig¬ 
ner  would  just  use  the  Marquise  move-grow  selection 
handles  to  demonstrate  the  behavior.  Of  course,  if  other 
objects  are  attached  to  the  moved  object  with  constraints, 
they  will  also  move. 

One  complication  is  that  often  the  object  that  the  mouse  is 
over  is  not  the  object  that  should  be  modined.  For  ex¬ 
ample,  with  selection  handles,  ihe  user  clicks  on  a  handle, 
but  wants  to  grow  the  object  underneath.  Marquise  knows 
about  this  special  case,  and  if  the  object  the  designer  moves 
is  attached  by  a  constraint  to  the  object  clicked  on,  then  this 
is  reflected  in  the  generated  behavior. 

Other  Properties  of  Objects 

Many  properties  of  objects  are  conuollcd  by  palettes,  but 
some  are  not.  In  some  graphical  editors,  a  menu  command 
or  double-clicking  on  an  objtxt  opens  a  property  sheet  or 
dialog  box  with  other  properties.  Marquise  provides  hooks 
to  pop  up  a  property  sheet  or  a  dialog  box  created  automati¬ 
cally  by  Jade  or  interactively  using  Gilt.  Of  course,  the 
designer  can  specify  which  fields  arc  presented. 
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Because  Garnet  uses  a  retained  object  model,  there  is  a 
standard  format  for  all  Garnet  objects.  Therefore,  common 
editing  commands  such  as  bringing  objects  to  the  top  (un¬ 
covered),  sending  to  the  bottom,  cuuing,  copying,  pasting, 
deleting  (clear),  duplicating,  and  printing  in  PostScript,  are 
all  provided.  P  designer  simply  demonstrates  what  ac¬ 
tion  causes  it  to  occur,  and  then  which  operation  is  de-sircd. 
Note  that  unlike  other  frameworks  that  provide  messages 
that  must  be  overridden  by  each  application,  the  code 
provided  by  Marquise  for  these  operations  can  often  be 
used  without  change. 

Semantic  Actions 

Naturally,  many  of  the  commands  in  a  graphical  editor  will 
invoke  application-specific  functions  (sometimes  called 
“scmartic  actions”).  Since  these  may  involve  arbitrary 
computation,  it  is  impossible  for  Marquise  to  infer  these 
from  a  demonstration.  However,  techniques  like  liiose 
previously  reported  for  Gilt  [7]  are  used  to  allow  the  ap¬ 
plication  procedures  to  be  independent  of  the  way  they  are 
invoked  (from  a  button,  menu,  double-click,  etc.)  and 
somewhat  independent  of  the  graphics.  However,  most 
functions  will  want  to  walk  through  the  graphical  objects 
computing  values,  so  they  will  clearly  have  to  look  at  the 
graphical  objects  in  the  window. 

If  the  result  of  the  function  is  a  change  to  the  graphic  ap¬ 
pearance  of  nodes,  then  this  can  be  specified  demonstra- 
tionally.  For  example,  a  “critical-path”  command  in  a 
graph  editor  might  want  all  the  nodes  on  the  critical  path  to 
turn  red.  The  designer  can  bring  up  a  property  sheet  On  the 
nodes,  add  an  on-critical-path  property,"*  and 
demonstrate  that  the  nodes  arc  black  when  it  is  NIL  and  red 
when  it  is  T.  Then,  the  critical-path  function  would  only  be 
responsible  for  setting  the  on-criticai-path  value  in 
each  node.  This  makes  the  applicauon  function  more  inde¬ 
pendent  of  the  graphical  rcspon.se  to  its  actions. 

Semantic  feedback  can  often  be  provided  m  the  same  way. 
For  example.  Marquise  supports  highlighting  of  only  those 
objects  that  an  object  is  being  dragged  can  legally  be 
dropped  into,  as  in  the  Macintosh  Finder.  Here,  a  function 
could  be  called  to  .set  a  particular  property  of  each  object  to 
T  or  NIL.  Then,  the  designer  would  demonstrate  the  ap¬ 
propriate  color  change  when  the  node  is  over  an  object 
which  has  the  value  T  for  that  property. 

Similarly,  if  the  application  wants  to  control  which  mode  is 
in  effect,  it  can  simply  change  the  value  of  one  of  the  mode 
variables,  and  the  designer  can  dcmonsU'alc  intcracuvciy 
whai  this  conu-ois. 

EDITING 

An  imporuini  aspect  of  an  inicraciivc  builder  is  how  to  edit 
the  interlaces  after  they  have  been  created.  ii  is  easy  tt  edit 
the  graphics,  since  they  can  be  directly  manipulaiaJ  in 
Build  mode.  For  the  behaviors,  the  feedback  window  oi 
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Figure  3  sJwws  the  pfopcrues.  When  in  Train  mode,  the 
feedback  window  continuail)'  shows  the  name  and 
properties  of  the  behaviors  being  executed,  so  the  designer 
can  detennine  whkh  behaviors  are  associated  with  which 
events,  lliere  are  also  commands  to  list  ail  the  behaviors, 
or  all  those  affecting  a  particuiar  object. 

CONCLUSION 

One  of  the  important  questions  for  an  interactive  tool  is 
what  is  the  range  of  interfaces  that  it  can  create.  Unfor¬ 
tunately,  this  is  very  difficult  to  quantify,  except  by  ex¬ 
ample.  Using  the  Lapidary,  Gilt  and  Marquise  tools  in 
GameL  it  is  possible  without  programming  to  create  com¬ 
plete  user  interfaces  like  those  in  Macintosh  MacDraw, 
MacOraw  n.  PowerPoinL  and  MacProject  II  (which  ore 
sui]aisingiy  different),  as  well  as  applications  with  various 
kinds  of  automatic  layout  for  nodes.  Later,  we  hope  to 
expand  the  range  of  Marquise  to  handle  gestural  inieif^aces 
(the  Garnet  toolkit  already  supports  gesture  recognition), 
and  those  with  3-D  graphics.  We  also  plan  to  add  support 
for  animations,  which  will  probably  make  possible  the 
demonsiration  of  various  visualizations  and  video  games. 
Another  addition  will  be  to  support  defining  consuamts 
^ong  objects  directly  in  Marquise,  probably  using 
demonstradonal  techniques  similar  to  Peridot  [3|  or  Druid 
[8], 

Marquise  is  sail  under  development  When  it  is  more 
robusL  we  will  perform  user-testing  to  see  if  the 
demoitstradons  and  feedback  are  understandable  to  both 
non-programmers  and  programmers.  After  that,  we  will 
release  it  for  general  use  as  part  of  the  Garnet  system.  All 
tins  will  help  show  what  kinds  of  behaviors  it  can  capture, 
and  we  will  continually  work  to  expand  the  range. 

We  believe  that  interactive,  demonstrational  creation  of 
user  interfaces  is  easier,  faster,  and  more  fun  than  program¬ 
ming.  Many  interactive  builders  have  already  shown  that 
dialog  boxes  and  forms  can  be  created  interactively.  Mar¬ 
quise  shows  that  direct  manipulation  techniques  can  be 
used  to  generate  the  user  interfaces  of  a  much  wider  class 
of  graphical  applications  as  well. 
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Screen  Shots  from  Selected  Garnet  Applications 

led  by 

Brad  A.  Myers 

School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Abstract 

As  of  the  winter  of  1993,  Garnet  has  been  used  by  over  40  projects  from  all  over  the  world.  The  following  pages 
show  pictures  of  a  few  of  those  applications.  None  of  the  applications  shown  in  the  pictures  were  developed  by  the 
Garnet  group — they  are  all  the  work  of  other  projects,  and  the  pictures  and  text  were  provided  by  the  developers. 
Most  were  generated  by  Garnet’s  code  that  produces  Postscript  files  directly  from  the  graphics  on  the  screen.  If  you 
are  using  Garnet  and  have  interesting  screen  shots,  please  send  them  along  with  a  description  of  your  project,  to 
garnetSca . cmu.edu. 

Many  of  these  pictures  were  originally  in  color.  If  you  have  a  color  printer  and  would  like  to  see  the  original 
pictures,  they  can  be  retrieved  by  anonymous  FTP  from  a.  gp.es.  cmu.edu  in  dircemry 
/  us  r /garnet /garnet /doc /usega  met /. 
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Companies 

1 .  Corporation  For  Open  Systems 

Automated  Protocol  Analysis/Re fcrence  Tool  (APART) 

Frank  J.  Wroblewski 

2.  Design  Research  Institute  (Cornell  &  Xerox) 

(various) 

Jim  Davis 

3.  Dcutchcs  Forschungszenorum  filer  Kuenstliche  Intclligcnz  GmbH 

COSMA 

Slc|)(icu  P.  Spockinan 

4.  GE  Research  and  Development  Center 

Metallurgical  Expert  Systems  for  Manufacturing 
K.  J.  Meltsner 

5.  GE  Research  and  Develojxneni  Center 

SKETCHER 
K.  J.  Meltsner 

6.  Hughes  AI  Center 

NLP  Project 

Seth  Goldman  or  (Diarlea  Dolan 

7.  Lawrence  Livermore  National  Lab 

PLANET  (Pump  Layout  ANd  Evaluation  Tool) 

Tom  Canales 

8.  Microelectronics  and  Computer  Technology  Corp.  (MCC) 

Scan:  Intelligent  Text  Retrieval 
Elaine  Rich 

9.  The  MITRE  Corporation 

AIMI  (An  htielligent  Multimedia  Interface) 

John  D.  Burger 

10.  National  Science  Center  Foundation 

Learning  Logk 
Lawrence  Freil 

11.  SiatSci 

GRAPHICAl-BELIEF 
Russell  Almond 

12.  The  MITRE  Corporation 

AIMI  (An  Intelligent  Multimedia  Interface) 

John  D.  Burger 

13.  Transarc  Corporation 

Lisp  GUI  for  Encina 
Mark  Sherman 

14.  U  S  WEST  Advanced  Technologies 

KBNL  natural  language  system 
Randall  Sparks 

15.  USC/ISI 

Humartoid 
Pedro  Szekeiy 

16.  USC/ISI 

SHELTER  knowledge-based  development  environment 
Pedro  Szekeiy 

Universities 

17.  Carnegie  Mellon  University,  CS 

Miro 

J.  D.  Tygar  and  J.  M.  Wing 

18.  Carnegie  Mellon  University,  CS 

Learning  Calendar  System 
Conrad  Poelman 

19.  Carnegie  Mellon  University,  CS 

Intcraclivc  Fiction  Editor 
Merrick  Furst 

20.  Carnegie  Mellon  University,  CS 

Redstone 
Jeff  Schiimmer 

21.  Carnegie  Mellon  University,  CS 

Architectural  Design 
Mikako  Harada 


22.  Carnegie  Mellon  University.  CS 

PURSUIT 

Francesmary  Modugno 

23.  Carnegie  Mellon  University,  ERDC 

LOOS 

Ulrich  Hemming  or  Robert  Coyne 

24.  Carnegie  Mellon  University,  Math 

Educaiicmai  Theorem  Proving  System 
Peter  Andrews 

25.  Carnegie  MclUai  Uitiversily,  I’sytli 

Soar  Crapiiies  interface 
Frank  Ritter 

26.  Carnegie  Mellon  University,  Robotics 

MICRO- BOSS 
Norman  Sadeh 

27.  Carnegie  Mellon  University,  Robotics 

SAGE  Dau  V  ,jualizauon 
Steve  Roth 

28.  MTT,  DepL  of  Brain  and  Cognitive  ScicrKcs 

SURF-HIPPO  Neuron  Simulator 
Lyle  J.  Borg-Graham 

29.  MIT.  LCS,  Computation  Structures  Group 

Debugging  tools  for  the  Id  Language 
Steve  Glim  and  R.  Paul  Johnson 

30.  State  University  of  New  York  at  Buffalo,  CS 

Air  Battle  Simulation 
Henry  Hexmoor 

31.  Sute  University  of  New  York  at  Buffalo.  CS 

SNePS  Graphical  UI 
John  S.  Lewocz 

32.  Tulane  University,  CS 

Natural  Language  Processing 
Robert  Cksidman 

33.  Tulane  University,  CS 

THESEUS 
Raymond  Lang 

34.  University  College  London 

The  Cognitive  Browser 
Gordon  Joly 

35.  University  of  Leeds 

Graphical  Multi-User  Domain  Designer 
Roderick  J.  Williams 

36.  University  of  Leeds 

CLARE 
Nikos  Drakos 

37.  University  of  Leeds 

ADVISOR 
Andrew  J.  Cole 

38.  University  of  Leeds 

PORSCHE 
Colin  Tattersall 

39.  University  of  Saskatchewan 

DISCUS  (Distributed  Computing  .it  ilic  U  of  S) 
Beth  Proisko  (User  Interface  only) 

40.  University  of  Southern  California 

Dynamic  Aggregation  in  Qiialitadvc  Simulaiion 
Nicolas  Rouquciic 

41.  University  of  Washington.  CS 

Multi-Gamct 
Michael  Sannclla 

42.  University  of  Washington.  CS 

Electronic  Encyclo(x;dia  Exploraioriimi 
Mike  Salisbury 


A  list  of  some  of  llic  projects  that  have  used  or  arc  using  the  Gurnet  user  interface  dcvclopmcni  environment,  as  t>l 
February,  1993.  If  you  arc  usitij*  Garnet  and  your  project  is  not  here,  plca.se  sent!  us  mail! 
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Nikos  Drakos 

Computer  Based  Learning  Unit,  University  of  Leeds,  UK. 

CLARE 

nikos@cbl . leeda . ac . uk 

A  collaborative  project  on  an  environment  for  the  specification,  testing,  maintenance  and  automatic  generauon  ol 
application  software.  The  context  is  batch  process  control  in  Chemical  Engineering  although  it  is  envisaged  that  the 
applicability  of  the  environment  will  be  more  general.  A  ‘domain  expert’  will  be  able  to  specify  knowledge  about 
plant  subsystems,  plant  configurations,  and  the  allowable  generic  operations  and  constraints  on  each  plant 
subsystem.  An  ‘application  engineer’  will  then  use  the  system  to  ‘glue’  together  predefined  operations  m  order  to 
make  specific  products.  The  system  will  then  generate  proce.ss  control  code  for  particular  target  hm-dwarc.  Garnet  is 
being  used  to  capture  and  visualise  plant  and  process  information  through  schematics,  prexess  diagrams,  interactive 
simulations  and  simple  animations. 

Hikes  Drakos,  "Object  Orientation  and  Visual  Programming",  in  Mamdouh  Ibrahim,  editor.  OOPSL/\  '^2  Wi/rkshop  on 
Object-Oriented  Programming  Languages:  The  Next  Generation.  Vancouver.  B.C.  Canada.  October  IS 
1992.  Extended  Abstract,  pp.  85-93. 


Kenneth  Meitsner 

General  Electric  Company,  Corporate  Research  and  Development 
Metallurgical  Expert  System 
meltsner0crd. ge . com 


A  mesh  created  using  a  virtual  aggregate  for  the  polygons  and  another  virtual  aggregate  for  the  square  knobs.  For 
the  polygons,  the  virtual  aggregate  is  passed  a  prototype  for  a  polygon,  and  an  array  coniaming  ihc  list  of  points  and 
the  color  for  each  polygon.  The  virtual  aggregate  then  pretends  to  allocate  an  object  for  each  element  of  the  array, 
but  actually  Just  draws  the  prototype  object  repeatedly. 


Kenneth  J.  Meitsner.  "A  Metallurgical  Expert  System  for  Interpreting  FEA,"  Journal  oj  S^etals.  Dct.  IWl.  vol  43.  no  10,  pp. 
15-17. 


Pedro  Szekely 

USC/ISI 

Humanoid 

szekelyQiai . edu 

Humanoid  is  a  user  inicrfacc  design  cnvironincni.  The  goal  of  Humanoid  is  lo  allow  micrlatc  designers  lo 
incrementally  construct  interfaces  by  composing  building  blocks  (ganict  gadgets  and  intcraciors)  Humanoid  allows 
designers  to  specify  the  conditions  when  gadgets  and  intcractors  arc  appropnaic  for  displaying/micracnng  widi 
information.  Given  and  application  data  soucturc,  Humanoid  constructs,  at  run-time,  a  display  appropriate  for 
interacting  with  the  given  data  structure.  Humanoid  keeps  track  of  Itow  the  tlisplay  dcpcntls  on  the  input  data,  so 
that  if  the  data  changes  at  run-time.  Humanoid  can  automatically  updatc/rcconstruct  the  di.splay. 

Pedro  Szekely,  Ping  Luo,  and  Robert  Neelies,  "Facilitating  the  Eaplotation  of  InicTfaec  Design  Alicrn,iiivcs:  The  HUMANOID 
Model  of  Interface  Design."  Proceedings  SIGCIir92:  Human  Factors  in  Computing  Systems  Monicrrcv, 
CA,  May.  I99Zpp,f')7.5l5. 
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Raymond  Lang 

Tulane  University,  Computer  Science  Department 
THESEUS 

langgrex . cs . tulane . edu 


These  are  images  of  windows  from  the  THESEUS  application  used  by  the  Tulane  University  Computer  Science 
Department  on  guided  tours  of  the  department  given  to  visiting  high  school  seniors  and  other  interested  parties. 
THESEUS  Is  intended  to  be  used  as  part  of  a  presentation  on  what  the  study  of  computer  science  entails.  It  does  this 
by  showing  graphically  the  progress  and  results  of  common  search  mcihtxls  applied  to  the  problem  of  finding  the 
exit  of  a  randomly  created  maze.  THESEUS  was  developed  in  CMU  Common  Lisp  version  16d  and  the  Garnet 
X- Windows  toolkit  version  2.01. 

R.  Raymond  Lang,  THESEUS:  Using  Maze  Search  to  Introduce  Computer  Science.  Technical  Report  Computer  Scicikc 

Department,  Tulane  University.  ••••.  1992. 
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Roderick  J.  Williams 

The  University  of  Leeds,  Leeds,  LS2  9JT,  UK. 

Cactus 

rodwgcbl . leeds .ac.uk 

A  system  has  been  developed  to  train  .senior  police  officers  to  manage  public  order  incidents,  such  as  marches.  The 
system  enables  pre-demonstration  planning,  die  management  of  (simulated)  events  requiring  meta-  and  contingency- 
planning,  and  post-event  debriefing.  The  training  incidents  arc  generated  hy  interactions  between  autonomous 
agents,  and  take  place  in  a  simulated  world  derived  from  digiuil  map  data.  In  addition  to  ihc  training  environment 
there  are  facilities  to  graphical  .specify  the  agents  behaviours. 

Hartley,  R.J..  Ravenscrofi,  A.  .ind  Williams,  R.J.  "C.tcius:  Command  and  Control  Training  Using  Knowicdgc-hascd 
Simulations."  Inleracttve  Leartung  Iniernational.  Vol.  8.  no  2.  1992.  op.  127- 136 
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Lyk  J.  Borg'Grabam 

MIT  Dq)t  of  Brain  and  Cognitive  Sciences 

Surf-Hippo 

lyle0ai .mit . edu 

The  SURF-HIPPO  Neuron  Simulaior  is  a  circuit  simulation  package  for  invesugatmg  morphometrically  and 
biophysically  detailed  models  of  single  neurons  and  small  networks  of  neurons.  SURF-HIPPO  allows  ready 
construction  of  multiple  cells  from  various  file  formats,  which  can  describe  complicated  dendritic  trees  in  3-space 
with  distributed  non-linearities  and  synaptic  contacts  between  cells.  Cell  gcomcu-ics  may  also  be  uaced  from  the 
histology  directly  on  the  screen,  using  the  mouse.  An  extensive  user  interlace  is  provided,  including  menus,  3D 
graphks  of  dendritic  trees,  and  data  plotting.  Data  files  may  also  be  saved  for  analysis  with  external  tools.  A 
research  version  of  SURF-HIPPO  (available  by  anonymous  ftp  from  rtp.ai.mit.edu  [pub/surf-hippo])  is  wntten  in 
LISP,  and  is  configured  to  run  using  the  public  domain  CMU  Common  Lisp  and  Garnet  packages.  Our  version  is 
compiled  for  SPARC  workstations,  and  should  be  easily  poned  to  other  UNIX  machines  running  X.  LISP  is  a  useful 
simulator  language  because  it  has  the  benefits  of  a  powerful  interpreted  script  language,  but  it  may  also  be  compiled. 
Thus  it  is  convenient  to  integrate  custom  code  into  SURF-HIPPO.  The  simulaior  may  also  be  us^  with  a  minimum 
of  programming  expertise,  if  desired. 

Borg-Graham,  L.  and  Grzywacz,  N.  M.  "A  Model  of  the  Direction  Selectivity  Circuit  in  Retina:  Transformations  by  Neurons 
Singly  and  in  Concert,”  in  Single  Neuron  Compuiaiton,  edited  by  T.  McKenna,  J.  Davis,  and  S.  F.  Zometzer. 
Academic  Press,  1992. 
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Roderick  J.  Williams 

The  University  of  Leeds,  Leeds,  LS2  9JT,  UK. 

GMD  (Graphical  Mud  (Multi-User  Domain)  Designer) 
roclw3cbl .  leeda  .ac.uk 

This  application  is  aimed  at  supporting  the  creation  of  text-based  multi-user  domains.  Current  techniques  use 
text-based  tools  to  create  these  environments,  but  these  tools  have  very  little  computer  support  so  complexity  and 
consistency  are  sacrificed.  Our  new  application  supports  the  graphical  creation  of  MUD  areas  and  enforces 
topological  constraints  together  with  hierarchical  grouping  of  features.  The  graphical  tool  can  be  used  in  a  number 
of  modes  which  allow  the  information  to  be  filtered,  zoomed  and  viewed  in  2.5  D.  Areas  created  can  be  printed  and 
additionally  they  can  be  saved  as  native  code  that  can  be  executed. 
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Steven  F.  Roth 

Carnegie  Mellon  University,  Robotics  Institute 
SAGE 

rothSiall . ri . emu . edu 

The  SAGE  project  is  developing  systems  which  automate  the  process  of  designing  presentations  of  information.  An 
automatic  presentation  system  is  an  intelligent  interface  component  which  receives  information  from  a  user  or 
application  program  and  designs  a  combination  of  graphics  and  text  that  effectively  conveys  it.  It’s  purpose  is  to 
assume  as  much  responsibility  for  designing  displays  as  required  by  a  user,  from  layout  and  color  decisions  to 
broader  decisions  about  the  types  of  charts,  tables  and  networks  that  can  be  composed  within  a  display.  The  SAGE 
project  is  developing  an  interactive  data  exploration  environment  whicn  contains  automatic  display  design 
ca{^ilities  integrated  with  data  navigation,  manipulation  and  modification  tools.  These  tools  are  being  used  to 
explore  large  amounts  of  diverse  data  from  marketing,  logistical,  real  estate,  census  and  other  dauibases. 

Roth,  S.F.  &  Maais,  J.A.  "Data  Characterization  for  Intelligent  Graphics  Presentation",  In  CUl'90:  Proceedings  of  the 
ACM/SIGCHI  Conference  onComputer  Human  Interaction,  Seattle.  April,  1990.  pages  193-200. 


Mike  Salisburj 

University  of  Washington,  Dqjaitment  of  Computer  Science 
Electronic  Encyclopedia  Exploratorium 
salisburScs . Washington . edu 


The  Electronic  Encyclopedia  Exploratorium  is  an  electronic  how-things-work  book.  It  allows  the  user  to  learn  about 
devices  by  experimenting  with  the  components  of  those  devices  in  a  lab  simulation  setting.  A  causal  model 
simulator  lies  beneath  the  user  interface  which  simulates  the  current  device  and  can  provide  causal  explanations  of 
the  results  of  that  simulation.  Other  high-level  tools  are  planned  for  future  enhancement. 


F.  G.  Amador,  D.  Berman,  A.  Boming,  T.  DeRose,  A.  Finkelstein,  D.  Neville,  Norge,  D.  Noikin,  D.  Salcsin.  M.  Salisbury, 
J.  Sherman,  Y.  Sun,  D.  S.  Weld,  and  G.  Winkenbach.  Electronic  "How  Things  Work"  Articles:  4 
Preliminary  Report.  University  of  Washington.  Department  of  Computer  Science  and  Engineering  Technical 
Report  92-04-08.  June,  1992. 
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Frank  E.  Ritter 

Departmoit  of  Psychology,  U.  of  Nottingham 
TfU  Devtlopmental  Soar  Interface 
Ritter0psyc . nott .ac.uk 

The  Developmental  Soar  Interface  provides  a  graphical  and  textual  interface  to  observe  and  modiiy  models 
(programs)  for  Soar,  an  AI  programming  language  that  also  realizes  a  unified  theory  of  cognition.  Garnet  is  used  to 
graphically  represent  Soar’s  goal  stack  and  intemal  state,  and  to  help  users  modify  and  observe  stfuctures  in  Soar. 

Ritter,  F.  E.  (1993)  TBPA:  A  methodology  and  software  environment  for  testing  process  models'  sequential  predictions  with 
protocols,  PhD  thesis.  Department  of  Psychology.  Camcgie-Mcllon  University.  Reprinted  as  icchrcport 
CMU-CS-93-101,  Camegic-Mellon  University. 


135- 


Second  Garnet  Compendium 


Stepbea  P.  Spackman 
Projekt  DISCO 

Deutches  Forschungszentrum  fiier  Kuenstlkhe  IntelUgenz  GmbH 
COSMA,  the  Cooperative  Scheduling  Management  Agent 
spackman0dfki.uni-3b.de  or  stephen0acm.org 

The  calendar  window  shows  the  dark  bar  of  the  past  sweeping,  one  pixel  each  half  hour  of  the  day  and  night,  across 
a  hmizontal  line  [not  visible  in  this  Postscript  image]  summarising  by  its  width  and  height  the  user’s  working  hours 
and  appointments,  tentative  and  firm.  The  marginal  time  tags  can  be  dragged  up  and  down,  and  it  will  eventually  be 
possible  to  type  over  the  top  of  them  to  jump  to  a  given  time.  The  datebook  window  presents  an  expanded  view  of 
time  as  an  infinite  tape  from  which  appointment  forms  can  be  popped  up  by  pointing  or  by  sweeping  out  free  areas. 
Most  importantly,  when  arrangements  involve  several  people  the  system  communicates  with  its  peers  and  with 
meeting  participants  by  reading  and  writing  email  in  German;  the  displays  are  updated  in  real  time. 

The  fields  of  the  appointment  form  are  semi-structured:  they  can  be  filled  in  with  the  help  of  menus  -  such  as  that 
visible  on  the  lower  window  -  that  drop  down  from  the  small  icons  on  the  right;  numeric,  date  and  time  values 
within  them  can  be  incremented  and  decremented  directly  with  mouse  buttons;  and  experienced  users  can  type 
structured  values  straight  in.  Unconstrained  German  text  (the  graphic  interface  will  soon  be  English/Frcnch/German 
trilingual,  but  the  natural  language  parser  and  generator  speak  only  German)  can  also  be  entered.  It  is  routed  to  the 
natural  language  system  for  analysis;  planned  improvements  to  the  pragmatics  module  will  allow  you  to  give  up  on 
the  structured  form  completely  and  type  informal  questions  and  insuuctions  into  the  notes  field,  os  you  might  lor  a 
human  secretary  who  had  stepped  out  of  the  room. 

The  work  underlying  this  picture  was  supported  by  a  research  grant.  FK2  ITW 
9002  0.  from  the  German  Bi'rdcsministerium  fuer  Forschung  und 
Technologie  to  the  DFKJ  project  DISCO. 

Elizabeth  A.  Hinkelman  and  Stephen  P.  Spackman,  “Abduciivc  Speech  Act  Recogniiion,  Corporate  Agents  and  the  COSMA 
System,”  in  Abduction,  Beliefs  and  Context:  Proceedings  of  ihe  second  ESPm'  PLUS  workshop  m 
computational  pragmatics.  W.  J.  Black  and  G.  Sabah  and  T.  J.  Wachtel,  eds.  Academic  Press.  1992. 


